ADA Programming Guide/ADA Programming Guide.iso/ada_gwu/ada.doc

Microsoft Windows Help File Content | 1996-01-30 | 899KB | 15,723 lines

        \uGWAda Help Engine\n
        \vAbout the GWAda Developing Environment\v10.
        \vAbout this help\v11.
        \vEditor Commands & Monitor Information\v12.
        \vTable of contents - LRM\v13.
        \vAlphabetical Index\v14.
        \vHow to use this Help Engine\v15.
\uAbout the GWAda Developing Environment\n
GWAda is a development  environment  built  around the  NYU  AdaEd inter-
preter. It allows  the  editing,  compiling,  binding  and  execution  of
Ada  83 programs.
1. To compile a program:
   Activate the top menu (F10) and select the Compile option.
1.1. To compile the current source:
     Activate the option "Current Unit".
     The source that will be compiled is the one that is being
     displayed on the screen.
     Be sure to setup properly your  working  directory. This is achieved
     by making of the "Directory" option  within the  "Option"  top  menu
     item.
1.2. To compile a source that is not being edited
     Activate the option "Select Unit" and enter the file path.
     Examples:  C:\my_prog.ada
                C:\others\*.ady
Hints: Save the  directory setup  (activate  "Write"  within the "Option"
       top menu item). The setup is saved in your current  directory onto
       file "GWADA.OPT".
       When this file is not present the default setup is  assumed having
       the current directory  as  the " Source Directory"  and  the  sub-
       directory "ada", within the current directory,  as  the  "Library"
       directory.
       Before compiling any program you must create a library.
       To create a library select the "New Library" option  within  the
       "Option" top menu item.
2. To bind a program select the Bind option (at the top menu). A  set  of
   units available for binding will be shown. Select one  at  each  time.
   The unit selected will then be binded. The  active  binded  units  are
   ready for interpretation.
3. To run a program select the Run option (at the top  menu).  A  set  of
   units available for interpretation will be shown. Select the  one  you
   want. To modify execution parameters (for the Ada interpreter) use the
   Parameters sub-option within the Options top menu item. To activate
   the monitor use the Parameters sub-option.
\uDisclaimer\n
    This program is distributed free of charges for educational  purposes
    only, but WITHOUT ANY WARRANTY; without even the implied warranty  of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Please send your comments and/or suggestions to:
    Dr. Michael B. Feldman
    EECS Department
    The George Washington University
    Washington, D.C. 20052
    [e-mail]
    Dr. Arthur V. Lopes
    Departamento de Engenharia El
trica - Escola Polit
cnica - Pr
dio 30
    Pontif
cia Universidade Cat
lica do Rio Grande do Sul - PUCRS
    Av. Ipiranga 6681
    90620 Porto Alegre - RS / Brazil
    [e-mail]
\uAbout this Help\n
The LRM (ANSI/MIL-STD-1815A-1983) was transformed into this on-line  help
system for use with the GWAda Development System by:
                               Ulrich Peters
                              Jerry Dressler
                              Rafael Presotto
supervised by
                            Dr. Arthur V. Lopes
     Pontif
cia Universidade Cat
lica do Rio Grande do Sul, Brazil
\uEditor Commands & Monitor Information\n
Here you will find a summary of the operations allowed by the GWada multi
text full screen editor.
The GWAda top menu becomes visible by depressing either the F10 or the
ESC key.
The editor works under two modes of operation:
        -Insert (Ins)
        -Overwrite (Ovr)
with up to 8 text files (to increase the  number  of  text  files  change
"#define AVL_MAX_WINDOWS     8";  this  define  is  located  within  file
"edit.h").
You may perform cut and paste operations among any of  the  editing  text
files.
To open a text file depress the Alt-F O keys. To  flip  among  open  text
files use the Alt-W keys.
To close the current text file use the Alt-F C  keys.  The  current  text
file is the file whose portion is being displayed onto the screen.
The above operations may also be performed by using the top menu. The top
menu is activated by depressing the F10 key. To  return  to  the  editing
mode depress the ESC key.
You are right now under control of a restricted execution of the  editor.
You can test many of the editor options while you read this text.
The operations allowed are shown below:
Key         Description/Action (Upper and lower case letter keys have
                                equal meanning)
Arrows      Allow to move the cursor left, right, up and down.
PgUp        Moves the cursor one page up.
PgDn        Moves the cursor one page down.
Home        Moves the cursor to the text line begin.
End         Moves the cursor to the text line end.
Ctrl-V
Ins         Changes from Ins mode to Ovr mode, and
                    from Ovr mode to Ins mode.
Del         Deletes the current character.
Backsp      The backspace key to the left of the current character.
Ctrl-N
ENTER       Creates a new line.
Tab         Insert up to k spaces according to the cursor location. The
            default identation lenght (k) is 4. It can be altered in the
            Options top menu (Alt-O I). This will also change the
            formating style when using the F7 key.
F1          Help on Hot Keys.
F5          Go to a specific text line (user is prompted).
F7          Generates package body templates from package specifications.
            Task body templates are also generated from task
            specifications written within a package spec.
            Before depressing the F7 key first position the cursor over the
            PACKAGE keyword that starts a given package specification. Only
            then depress the F7 key. Answer Y if the template is to be
            appended to the end of the corrent editing text. Otherwise you
            will be prompted for the name of the file that will contain the
            resulting package body template. The template will be inserted
            into this file.
            While this option performs some syntax check,it is assumed that
            the package specification is correct.
F8          Search Help on the LRM. In the editor mode press the F8 key
            when the cursor is over a word. If this word is in the LRM
            index you will be given a menu with the matches for that word.
            Select one of the entries and the related LRM text will be
            displayed.
F10         Brings the GWAda Development Environment Menu (Top Menu).
ESC         Returns to the editing mode from the Top Menu.
Ctrl-y      Deletes the current line (idential to Alt-E D).
Ctrl-g      Deletes current character (identical to Del key).
Ctrl-k b    Mark text's block begin (identical to Alt-E M).

********    The second key, as "b", above should be depressed without
            holding the Ctrl key.
Ctrl-k k    Mark text's block end (identical to Alt-E M).
Ctrl-k c    Copypreviously marked block (same as Alt-E C).
Ctrl-k s    Saves the current file.
Ctrl-D      Moves right.
Ctrl-Left
Ctrl-A      Move back one word.
Ctrl-Right
Ctrl-F      Move forward one word.
Ctrl-Q R    Move to begin of file.
Ctrl-Q C    Move to end of file.
Ctrl-Q Y    Delete from the current position to the line's end.
Alt-F
F2          Activate File menu.
Alt-F O     Opens a file for editing.
Alt-F C     Closes the current file being edited.
Alt-F S     Save the text to disk.
Alt-F I     Shows general information.
Shift-F9
Alt-F D     Starts a DOS shell.
Alt-F Q     Quits the program.
Alt-F4      Quits the program.
Alt-E       Activate Edit menu.
Alt-E I     Inserts a text file to the right of the current cursor
            location.
Alt-E D     Deletes the current line.
Alt-E F     Scans the text looking for the first occurence of a string.
Alt-E R     Perform text replacement.
Alt-E M     Used to mark a block of text for future duplication or
            disk transfer.
Alt-E C     Inserts a previously marked text block.
Alt-E W     Creates a disk file containing a previously marked text
            block.
Alt-E S     Allows the insertion of special ASCII symbols.
Alt-C       Activate Compile menu.
Alt-C C     Compile the current text file.
Alt-C S     Slect a non editing text file for compilation.
Alt-B       Activates the Bind menu.
Alt-R       Activates the Run menu.
Alt-W       Activates the Window menu.
Alt-W n     Sets the text file name, n, as the current editing file.
Alt-O       Activates the Option menu.
Alt-O D     Used to set the source file and library directory.
Alt-O M     Access the monitoring/debugging tools.
Alt-O F     Used to set compiler and interpreter options.
Alt-O C     Allows to customize the editor/environment colors.
Alt-O I     Used to set the identation size (default = 4).
Alt-O R     Reads in the options file previously saved.
Alt-O W     Saves to disk the current options.
ALt-O S     Overwrite current options with the default options.
Alt-A       Activates the Ada menu.
            It allows text insertion of language constructs.
Alt-H       Activates the Help menu.
Alt-H H     Brings the Help engine.
Alt-H F     Show some of the hot keys (same as F1).
Dr. Arthur V. Lopes
Departamento de Engenharia El
trica - Escola Polit
cnica - Pr
dio 30
Pontif
cia Universidade Cat
lica do Rio Grande do Sul - PUCRS
Av. Ipiranga 6681
90620 Porto Alegre - RS / Brazil
[e-mail]   [e-mail]
\uMonitor Information\n
    The GWUMon Parallel Ada Monitor provides a shell around the
NYUAda Run Time System(RTS).  This monitor allows the user to
set tasking options for the RTS, and to monitor the execution
of the RTS.  This monitoring shows the source code for the
program which is running, or the execution percentage of the
various tasks of the current program.
\uIntroduction\n
    This is an introduction to the GWUMon execution shell.  This
shell allows a user to interact with the NYUAda Run Time System
(RTS) while the RTS is executing the user program.  This
interaction with the RTS allows the user to see the program
statement as they are being executed, and to monitor the CPU
as the program runs.
    This README file walks the user through an initial run of the
monitor. Note that there are several Ada programs which are given
with this distribution. One of them, TEST1.ADA, will be used to
give a walk through of the system.
\uSystem Setup\n
IF YOU HAVE NOT PREVIOUSLY INSTALLED NYUAda or GWAda
    If you have never installed NYUAda or GWAda, then use the
following directions to install the GWUMon system.
    First, make a directory where the programs which will be used
by GWUMon will be stored, and change to that directory.  It is
suggested that the directory "ADAED" be used.  Assuming that this
directory will be named "ADAED" and will be on the "C:" drive,
this can be done by typing:
    c:
    cd \
    mkdir adaed
    cd c:\adaed
    The programs which install GWUMon are contained in a self
extracting archive called GWUARC.EXE.  This is a selfextracting
archieve.  To load the GWUMon system, simply run the archive
executable.  Assuming that the archive is on the "A:" drive,
type the following:
    c:
    cd \adaed
    a:\gwuarc
    The GWUMon system should now been installed.  Several system
variables need to be set or changed to run the ADAED system.  A
batch program, MONSETUP.BAT, is included with the distribution.
If you wish, the following instructions will allow you to use the
GWUMon without modifying this file. Otherwise, this .BAT file will
give you instructions on what needs to be modified in your
AUTOEXEC.BAT to allow GWUMon to run.
    If you are not going to modify MONSETUP.BAT, then the
following instructions will allow you to setup your computer to
run the monitor. One time only, type the following:
    c:
    cd \adaed
    monsetup
    mkdir myprogs
    cd \adaed\myprogs
    Each time you wish to edit or compile and modify a program,
always  make sure that you have run monsetup, that you are in the
"\adaed\myprogs" directory, ie:
    c:
    cd \adaed
    monsetup
    cd myprogs
IF YOU ALREADY HAVE INSTALLED NYUAda or GWAda
    If you already have installed NYUAda or GWAda, you probably are
familar with how they work.  GWUMon is simply an additional shell to
be used around ADAEXEC.  Therefore, these instructions will assume
that you are familar with NYUAda.
    First, change to the directory where you have stored NYUAda or
GWAda. Save the files in this directory.  GWUMon will overwrite all
the old NYUAda and GWAda files.  Note that GWUMon uses NYUAda as a
baseline, but it does not work with the unchanged NYUAda programs.
Do not try to run GWUMon with any NYUAda programs which have not
come with the GWUMon distribution.
    After you have saved the files in your NYUAda directory,
unarchive the files from GWUARC.  Since GWUARC is a self
extracting archive, the files can be retrieve by simply running
GWUARC from the directory where you wish to place the files.
    Once you have GWUMon installed, all your NYUAda and GWAda
programs should work as before with only one modification.
Since GWUMon uses a slightly different AdaEd interpreter, the
library files are changed slightly.  You should therefore make
all your libraries new, and you will have to recompile and
bind all your programs.
\uRunning thr Monitor\n
RUNNING FROM THE COMMAND LINE
    Although GWUMon was written to be integrated into GWAda, it
can be run standalone from the command line.  If you wish to do
this, you should make sure that all your compiles include the "-a"
option, ie:
    adacomp -a -b dummy.ada
    When you run GWUMon, the command line options are exactly the
same as the options for "adaexec", so you should check the NYUAda
documentation if you wish to set these options.  Note that if you
don't set the "-a" option in the compile, the monitor will not
work.
\uRunning from GWAda\n
    If you are running GWUMon from GWAda, you do not have to worry
about any compile options, etc.  GWAda sets them for you.  From the
command line, type "GWAda", and the GWAda system will start up.
    To run the monitor from GWAda, go to the options menu, and choose
the option "Run Monitor".  This is a toggle which turns the monitor
on and off. If you choose not to run the monitor, the NYU AdaExec
program is run as usual from GWAda.
\uA First Run of GWUMon\n
    This section will give you a step by step walk through on how to
use GWUMon from GWAda.
    1 - Copy the ada program "TEST1.ADA" from the directory \ADAED
        to the directory \ADAED\MYPROGS
    2 - Start GWAda by typing "GWAda TEST1.ADA"
    3 - The GWAda editor should now be running, with the source for
        the program TEST1.ADA in the window.  First, create a new
        library as follows:

        Hit the "ESC" key.
        Type "O" to select the options menu.
        Type "N" to select a new library.
        A New library has been created.
    4 - You should still be on the menu bar.  Type "C" to select
        compile.
    5 - When the compile is done, you will no longer have the menu
        bar.  Type "ESC" to bring up the menu bar, and type "B" to
        bind the program.
    6 - You will be asked for the program to bind.  Select "test1".
        The program is now bound.
    7 - Type "O" to select options again.  Use the down arrow key
        to select the option "Run Monitor".  Hit enter to select
        this option.
    8 - Type "R" to run the program.  When asked what program to
        run, select "test1".
    9 - You should now have up the monitor screen.  We will use all
        the default options, except for the delay.  This is the first
        field.  Set this to 5 by typing a "5" followed by blanks until
        all the "0"'s are gone.  Hit "ESC", and the monitor will
        start.
    10 - Note that the monitor is now running,  Windows with the
        source programs should be coming up titled "main", "task1",
        and "task2".
    11 - Once all three windows are up, type "CTRL-D" to bring up the
        setup window.  Use the "ENTER" key to go to the Window Type
        field (the last field).  Use the down arrow key to select
        "Two Windows, Vertical".  Hit "ESC" to leave the setup
        screen.
    12 - The Control screen should now be up.  Use the arrow key to
        go to task1.  Toggle the "Window ON" (WON) using the "t" key.
        Do the same for task2.
    13 - Allow the program to run.  We have now gone through the
        basics of how the monitor program works.
\uGWUMon Options\n
    There are many options which can be set in GWUMon.  The best way
to find out what they all are is to experiment with the system.  This
section will give an overview of what the options are, and how to use
them.
\uSetup Screen\n
    The set up screen is the screen which initially comes up when you
    run GWUMon.  The following can be set from the setup Screen:
    Delay Rate - This is the amount to delay the monitor on each clock
    cycle. Note that a clock cycle is one pass through the interpreter.
    Cycles for Reporting Exec % - If Type of Monitoring is Exec %, then
    this tells how many cycles to run between reporting.
    Delay time - If the Type of Delay is set to Scaled then this is the
    number of clock ticks to be interpreted as 1 second.
    RR statments - If Type of Tasking is set to Round Robin, then this
    is the number of cycles between task switches.
    Type of Tasking - This is the task type model.  It can be set to
    Round Robin or Run Til Blocked.
    Type of Delay - The type of delay can be either Real ( 1 second is
    a real time second), or Scaled ( 1 second is some number of clock
    cycles.
    Type of Monitoring - This can be either None (No monitoring is
    used), Line (show the lines of code as they are executed ),  or
    Exec % (show the execution % for each task at the interval
    specified above).
    Line Trace - Turns Line Tracing on.  This stops the monitor after
    each line on the current monitor screen is executed.
    Task Trace - Turns Task Tracing on.  This stops the monitor after
    each task switch for a task on the current monitor  screen.
    Type of Monitoring Window - Type of window to use  in Line
    Monitoring  Mode.
    You can show 1 - 4 tasks in 4 different ways.
    NOTE:  Help for the fields in this screen can be gotten by typing
           a "?".
    The reason a "?" was choosen, rather than the normal "CTRL-H" is
    that a CTRL-H and BACKSPACE are equivalent, and the BACKSPACE is
    needed to edit the fields.
\uControl Screen\n
    The Control Screen allows the user to choose which tasks they wish
    to see on the screen when the monitor is running.  It tells the
    current status of the tasks, and allows the user to choose which
    tasks they wish to monitor.  The field WON tells which windows are
    currently being monitored, if the field is "yes", the task is
    attatched to a monitor window.  This WON field can be toggled by
    using the arrow keys to position yourself on the task you want to
    change, and typing the "t" key.
    If there are more then one screens worth of tasks, then hitting the
    down arrrow on the last task on the screen will bring up the next
    series of tasks.
\uOptions when Line Monitor is Running\n
    Line monitoring allows the user to see what lines are being executed
    in each task as they are running.
    Many of the options which are available from the SETUP screen which
    pertain to line monitoring can be set with a single key stroke while
    the monitor is running.  This is to save the user the time of having
    to go into the SETUP screen and change the options.  These commands
    are summarized here:
    Up Arr - doubles the speed of the interpreter (ie. cuts the
             delay in half.)
    Dn Arr - halves the speed of the interpreter (ie. doubles the
             delay.)
    ctrl a - brings up the control screen to allow the user to
             set the tasks they would like to monitor.
    ctrl b - stops the monitor from running.  This options allows
             the user to run their program without any monitor output.
             Note that the delay still is in effect, and the program can
             be slowed down or sped up.
    ctrl c or ESC - stop the execution of the monitor.
    ctrl d - Brings up the setup screen.
    ctrl h - Brings up the help screen.
    ctrl l - Sets line step mode, where the monitor stops after each
             line that is in a currently active monitor window has been
             executed.
    ctrl t - Sets line task step, where the monitor stops after each
             task switch that is in a currently active monitor window
             has been executed.
    The status codes for line monitoring are as follows:
        R - Wait on Rendezvous      M - Rendezvous Meet
        D - Wait on Delay           * - Task Ready to Run
        --> Task currently running
    Note that all this information can be obtained by typing "CTRL-H"
    when the line monitor is running.
\uExecution Percentage Window\n
    The executions percent window allows the user to compare the
    relative number of clock cycles each task uses.  The only option
    on this window is to turn the monitoring by using the CTRL-B key.
\uKnown Bugs and Other Hints\n
     There are a number of known bugs and problems which can occur
     when using the monitor.  These will be fixed for the next
     release.
    1 - Too many key strokes which are not processed can cause the
        monitor to hang.  For example, if you hit alot of DOWN ARROW
        keys to slow the monitor down, the system will take longer to
        process these keys, and eventually will hang.  If this happens,
        the computer must be rebooted.
    2 - The monitor comes up but no source lines are displayed and
        the task line is not advanced.  This can be caused by the
        source program not being compiled with the "-a" option.  If
        you are compiling from the command line, make sure you use
        the "-a" option on the compile.
Charles W. Kann
EECS Department
The George Washington University
Washington, D.C. 20052
[e-mail]
   \uTable of contents - LRM\n
1  \vIntroduction\v100.
2  \vLexical Elements\v200.
3  \vDeclarations and Types\v300.
4  \vNames and Expressions\v400.
5  \vStatements\v500.
6  \vSubprograms\v600.
7  \vPackages\v700.
8  \vVisibility Rules\v800.
9  \vTasks\v900.
10 \vProgram Structure and Compilation Issues\v1000.
11 \vExceptions\v1100.
12 \vGeneric Units\v1200.
13 \vRepresentation Clauses and Implementation Dependent Features\v1300.
14 \vInput-Output\v1400.
   \uAppendix\n
 A \vPredefined Language Attributes\v1500.
 B \vPredefined Language Pragmas\v1600.
 C \vPredefined Language Environment\v1700.
 D \vGlossary\v1800.
 E \vSyntax Summary\v1900.
 F \vImplementation Dependent Characteristics\v2000.
\uAlphabetical Index\n
 Abnormal Task
\v A \v20.
 Attribute designator
 BASE predefined attribute)
\v B \v21.
 Box compound delimiter
 CALENDAR (predefined library package)
\v C \v22.
 CURRENT_OUTPUT (text_io function)
 DATA_ERROR (input-output exception)
\v D \v23.
 DURATION (predefined type)
 Effect
\v E \v24.
 External file
 Factor
\v F \v25.
 Function specification
 Garbarge collection
\v G \v26.
 Greater than or equal
 Handler
\v H \v27.
 Hyphen character
 Identifier
\v I \v28.
 Iteration scheme
 Label
\v L \v29.
 Lower case letter
 Machine code insertion
\v M \v30.
 Mutually recursive types
 NAME (input-output function)
\v N \v31.
 NUMERIC_ERROR (predefined exception)
 Object
\v O \v32.
 Overloading
 PACK (predefined pragma)
\v P \v33.
 PUT (text_io procedure)
 Qualification
\v Q \v34.
 Quotation character
 Radix of a floating point type
\v R \v35.
 Run time check
 Safe interval
\v S \v36.
 SYSTEM_NAME (predefined pragma)
 Tabulation
\v T \v37.
 Type with discriminants
 Unary adding operator
\v U \v38.
 USE_ERROR (input-output exception)
 VAL (predefined attribute)
\v V \v39.
 Visible part (of a package)
 Wait
\v W \v40.
 Writing an output file
 Xor operator
\v   \v41.
 YEAR (predefined function)
\u How to use this Help Engine\n
       You can operate this hypertext program  with your keyboard  or  with
a two-button mouse. For best visualibility, you should use a color monitor.
       \uButtons\n
\uF1\n     Returns to the main help window.
\uALT-F1\n Returns to the previous help window, if any.
\n  Allows to select keywords in the current window.
\uENTER\n  Activates selected keyword, changing the current window.
\uESC\n    Terminates the work with the Help-Engine.
       \uUsing keyboard\n
       To  scroll  the  actual window, you can use the \uPgUp\n / \uPgDn\n keys, as
well as the direction keys (\u
\n and \u
\n). With \uHome\n you can go back to the  top
of the current help text, with \uEnd\n you jump to the end of the text.
       Please note that scrolling is only avaliable  if  the  current  help
text is longer as 18 lines of text. This can be controlled  by  the  slider
\n" at the right border of the window: Only if the slider is present in the
scroll bar, scrolling will be possible.
       You may note that some words are marked  \vlike this\v16.. Those words  are
special terms, which are explained nearer in another help text.  To  go  to
this  specific help  text, simply select the word, pressing the \uTab\n key. If
there  are  more than one keywords present, for each time you press the \uTab\n
key,  the cursor will move one keyword forward. If you press \uShift-Tab\n, the
cursor will move one keyword backwards.  Press \uEnter\n to activate the selec-
ted keyword.
       If you wish to go to the opening screen, press \uF1\n.
       To return to the previous help text, you should press \uAlt-F1\n.
       To finish the work, simply press \uEsc\n.
       \uUsing mouse\n
       To scroll the window, you can place the mouse cursor at  the  scroll
bar, and press a mouse button. The program  will try to place the slider at
the  current mouse  cursor  position. If the  help text is  very short, the
screen may flicker, showing two pages of the current help alternatly.
       You can use the same buttons  at the bottom  of the  window, placing
the cursor over the buttons and pressing a mouse button.
       If you press the left mouse button  over the  word \u
\n,  you  will
move the selection cursor one keyword forward,  pressing  the  right  mouse
button instead, you will move backwards.
       You can also activate the keywords directly with the mouse: you have
only to  move the mouse  cursor  over the word and press a button. The word
will be selected and activated when releasing the mouse button.
       \uNote\n
       Sometimes the buttons are shown "dimmed" in the button bar. This may
occour when the button may not be activated at this moment.
\uThis is only a test.\n
The text you activated does not have any special meaning.
Please use \uAlt-F1\n to return to the previous help text, or \uEsc\n to abort.
You may want to return \vto the previous help text\v15. now.
\u- A -\n
\vAbnormal task\v913.
\vAbort statement\v913.
\vAbs unary operator\v417.
\vAbsolute value operation\v417.
\vAccept alternative (of a selective wait)\v908.
\vAccept statement\v905.
\vAccess to external files\v1402.
\vAccess type\v330.
\vAccess type definition\v330.
\vAccuracy of a numeric operation\v418.
\vAccuracy of a numeric operation of a universal type\v423.
\vActual parameter\v607.
\vActual parameter part\v606.
\vAddition operation\v414.
\vAddition accuracy for a real type\v418.
\vADDRESS (predefined attribute)\v1310.
\vAddress clause\v1305.
\vAFT (predefined attribute) for a fixed point\v320.
\vAft field of text_io input or output\v1416.
\vAggregate\v407.
\vAlignment clause (in a record representation clause)\v1304.
\vAll in a selected component\v404.
\vAllocation of processing resources\v911.
\vAllocator\v421.
\vAllowed\v108.
\vAncestor library unit\v1004.
\vAnonymous type\v306.
\vANSI (american national standards institute)\v201.
\vApostrophe character\v201.
       \vin a character literal\v207.
       \vdelimiter\v202.
       \vin an attribute\v405.
       \vof a qualified expression\v420.
\vApply\v1002.
\vAppropriate for a type\v401.
       \vfor an array type\v402.
       \vfor a record type\v404.
       \vfor a task type\v404.
       \vprefix of an attribute\v405.
\vArbitrary selection of select alternatives\v908.
\vArgument association in a pragma\v210.
\vArgument identifier in a pragma\v210.
\vArithmetic operator\v411.
\vArray aggregate\v409.
\vArray assignment\v503.
\vArray type\v321.
\vArray type definition\v321.
\vArrow compound delimiter\v202.
\vASCII (american standard code for information interchange)\v201.
\vASCII (predefined library package)\v312.
\vAssignment compound delimiter\v202.
       \vin an object declaration\v303.
\vAssignment operation\v502.
\vAssignment statement\v502.
\vAssociated declarative region of a declaration or statement\v801.
\vAttribute\v405.
\vAttribute designator\v405.
\u- B -\n
\vBASE (predefined attribute)\v308.
     \vfor an access type\v332.
     \vfor an array type\v323.
     \vfor a discrete type\v315.
     \vfor a fixed point type\v320.
     \vfor a floating point type\v318.
     \vfor a private type\v706.
     \vfor a record type\v708.
\vBase type (of a subtype)\v305.
     \vas a static subtype\v422.
     \vas target type of a conversion\v419.
     \vdue to elaboration of a type definition\v306.
     \vof an array type 3.6;\v403.
     \vof a derived subtype\v309.
     \vof a discriminant determining the set of choices of a variant part\v328.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
     \vof a formal parameter of a generic formal subprogram\v1204.
     \vof an integer type\v314.
     \vof a parent subtype\v309.
     \vof a qualified expression\v420.
     \vof a type mark\v307.
     \vof a type mark in a membership test\v413.
     \vof the discrete range in a loop parameter specification\v506.
     \vof the expression in a case statement\v505.
     \vof the result of a generic formal function\v1204.
     \vof the result subtype of a function\v509.
     \vof the subtype indication in an access type definition\v330.
     \vof the type in the declaration of a generic formal object\v1202.
     \vof the type mark in a renaming declaration\v805.
\vBased literal\v206.
     \vas a numeric literal\v204.
\vBasic character\v201.
\vBasic character set\v201.
     \vis sufficient for a program text\v212.
\vBasic declaration\v301.
     \vas a basic declarative item\v333.
\vBasic declarative item\v333.
     \vin a package specification\v701.
\vBasic graphic character\v201.
\vBasic operation\v308.
     \vaccuracy for a real type\v418.
     \vimplicitly declared\v301.
     \vof an access type\v332.
     \vof an array type\v323.
     \vof a derived type\v309.
     \vof a discrete type\v315.
     \vof a fixed point type\v320.
     \vof a floating point type\v318.
     \vof a limited type\v708.
     \vof a private type\v706.
     \vof a record type\v329.
     \vof a task type\v912.
     \vpropagating an exception\v1108.
     \vraising an exception\v1105.
     \vwhich is an attribute\v405.
\uBelong\n
     \vto a range\v310.
     \vto a subtype\v305.
     \vto a subtype of an access type\v330.
\vBinary adding operator\v411.
     \vfor time predefined type\v906.
     \vin a simple expression\v410.
     \voverloaded\v611.
\vBinary operation\v411.
\vBlank skipped by a text_io procedure\v1413.
\vBlock name\v507.
     \vdeclaration\v501.
     \vimplicitly declared\v301.
\vBlock statement\v507.
     \vas a compound statement\v501.
     \vas a declarative region\v801.
     \ventity denoted by an expanded name\v404.
     \vhaving dependent tasks\v904.
     \vincluding an exception handler\v1102.
     \vincluding an implicit declaration\v501.
     \vincluding a suppress pragma\v1109.
     \vraising an exception\v1105.
\vBody\v333.
     \vas a later declarative item\v333.
\vBody stub\v1004.
     \vacting as a subprogram declaration\v603.
     \vas a body\v333.
     \vas a portion of a declarative region\v801.
     \vmust be in the same declarative part as the declaration\v333.
\vBOOLEAN (predefined type)\v313.
     \vderived\v309.
     \vresult of a condition\v504.
     \vresult of an explicitly declared equality operator\v611.
\vBoolean type\v313.
     \voperaion\v315.
     \voperation comparing real operands\v418.
\vBound of an array\v321.
     \vaggregate\v409.
     \vignored due to index_check suppression\v1109.
     \vinitialization in an allocator constrains the allocated object\v421.
     \vresult of an operation\v412.
\vBound of a range\v310.
     \vof a discrete range in a slice\v403.
     \vof a discrete range is of universal_integer type\v322.
     \vof a static discrete range\v422.
\vBound of a scalar type\v310.
\vBound of a slice\v403.
\vBox compound delimiter\v202.
     \vin a generic parameter declaration\v1201.
     \vin an index subtype definition\v321.
\u- C -\n
\vCALENDAR (predefined library package)\v906.
\uCALLABLE (predefined attribute)\n
     \vfor an abnormal task\v913.
     \vfor a task object\v912.
\vCalling conventions of another language system\v1313.
\vCancelation of an entry call statement\v909.
\vCarriage return format effector\v201.
\vCase statement\v505.
     \vas a compound statement\v501.
\vCase statement alternative\v505.
\vCatenation operation\v414.
     \vfor an array type\v323.
     \vin a replacement of a string literal\v212.
\vCatenation operator\v411.
\vCharacter\v201.
     \vin a lexical element\v200.
     \vnames of characters\v201.
     \vreplacement in program text\v212.
\vCHARACTER (predefined type)\v312.
     \vas the component type of the string type\v324.
\vCharacter literal\v207.
     \vas a basic operation\v308.
     \vas an enumeration literal\v311.
     \vas a name\v401.
     \vas a selector\v404.
     \vdeclared by an enumeration literal specification\v301.
     \vin a static expression\v422.
     \vin homograph declarations\v803.
     \vmust be visible at the place of a string literal\v406.
\vCharacter types\v312.
     \voperation\v315.
     \vsubject to an attribute\v315.
\vChoice\v328.
     \vin an aggregate\v407.
     \vin an array aggregate\v409.
     \vin a case statement alternative\v505.
     \vin a component association\v407.
     \vin a record aggregate\v408.
     \vin a variant of a record type definition\v328.
\vCircularity in dependencies between compilation units\v1008.
\vClass of type\v305.
     \vof a derived type\v309.
\vCLOCK (predefined function)\v906.
\uCLOSE (input-output procedure)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vClosed alternative (of a selective wait)\v908.
\vClosed file\v1401.
\vCode statement\v1312.
     \vas a simple statement\v501.
\vCOL (text_io function)\v1412.
        \vraising an exception\v1419.
\vCollection (of an access type)\v330.
     \vof a derived access type\v1302.
\vColon character\v201.
     \vreplacing sharp character\v212.
\vColon delimiter\v202.
\vColumn\v1412.
\uComma\n
     \vcharacter\v201.
     \vdelimiter\v202.
\vComment\v209.
     \vin a conforming construct\v604.
\vCommunication of values between tasks\v905.
\vCompatibility (of constraints)\v307.
     \vfailure not causing constraint_error\v1109.
     \vof a discrete range with an index subtype\v322.
     \vof discriminant constraints\v327.
     \vof fixed point constraints\v319.
     \vof floating point constraints\v317.
     \vof index constraints\v322.
     \vof range constraints\v310.
\vCompilation\v1001.
     \vas a sequence of lexical elements\v200.
     \vincluding an inline pragma\v605.
\vCompilation unit\v1001.
     \vcompiled after library units named in its context clause\v1006.
     \vfollowed by an inline pragma\v605.
     \vwith a context clause\v1002.
     \vwith a use clause\v804.
\vCompile time evaluation of expressions\v1009.
\vCompiler\v1007.
\vCompleted block statement\v904.
\vCompleted subprogram\v904.
\vCompleted task\v904.
     \vas recipient of an entry call\v905.
     \vbecoming abnormal\v913.
     \vcompletion during activation\v903.
     \vdue to an exception in the task body\v1105.
\vComponent (of a composite type)\v305.
     \vcombined by aggregate\v407.
     \vdepending on a discriminant\v326.
     \vname starting with a prefix\v401.
     \vof an array\v321.
     \vof a constant\v303.
     \vof a derived type\v309.
     \vof an object\v302.
     \vof a private type\v706.
     \vof a record\v325.
     \vof a variable\v303.
     \vsimple name as a choice\v328.
     \vsubtype\v325.
     \vsubtype itself a composite type\v322.
     \vthat is a task object\v903.
     \vwhose type is a limited type\v708.
\vComponent association\v407.
     \vin an aggregate\v407.
     \vincluding an expression which is an array aggregate\v409.
     \vnamed component association\v407.
     \vnamed component association for selective visibility\v803.
     \vpositional component association\v407.
\vComponent clause (in a record representation clause)\v1304.
\vComponent declaration\v325.
     \vas part of a basic declaration\v301.
     \vhaving an extended scope\v802.
     \vin a component list\v325.
     \vof an array object\v322.
     \vof a record object\v327.
     \vvisibility\v803.
\vComponent list\v325.
     \vin a record type definition\v325.
     \vin a variant\v328.
\vComponent subtype definition\v325.
     \vin a component declaration\v325.
Component type
     \vcatenation with an array type\v414.
     object initialization [see: initial value]
     \vof an expression in an array aggregate\v409.
     \vof an expression in a record aggregate\v408.
     \vof a generic formal array type\v1210.
     \voperation determining a composite type operation\v412.
\vComposite type\v305.
     \vincluding a limited subcomponent\v708.
     \vincluding a task subcomponent\v902.
     \vobject initialization\v303.
     \vof an aggregate\v407.
     \vwith a private type component\v706.
\vCompound delimiter\v202.
     \vnames of delimiters\v202.
\vCompound statement\v501.
     \vincluding the destination of a goto statement\v510.
\vCondition\v504.
     \vdetermining an open alternative of a selective wait\v908.
     \vin an exit statement\v508.
     \vin an if statement\v504.
     \vin a while iteration scheme\v506.
\vConditional compilation\v1009.
\vConditional entry call\v909.
     \vand renamed entries\v805.
     \vsubject to an address clause\v1306.
\vConforming\v604.
     \vdiscriminant parts\v604.
     \vformal parts\v604.
     \vformal parts in entry declarations and accept statements\v905.
     \vsubprogram specifications\v604.
     \vsubprogram specifications in body stub and subunit\v1004.
     \vtype marks\v604.
\vConstant\v303.
     \vaccess object\v330.
     \vformal parameter\v602.
     \vin a static expression\v422.
     \vrenamed\v805.
     \vthat is a slice\v403.
\vConstant declaration\v303.
     \vas a full declaration\v707.
     \vwith an array type\v322.
     \vwith a record type\v327.
CONSTRAINED (predefined attribute)
     \vfor an object of a type with discriminants\v329.
     \vfor a private type\v706.
\vConstrained array definition\v321.
     \vin an object declaration\v302.
\vConstrained array type\v321.
\vConstrained subtype\v305.
     \vdue to elaboration of a type definition\v306.
     \vdue to the elaboration of a derived type definition\v309.
     \vobject declarations\v303.
     \vof a subtype indication in an allocator\v421.
\vConstraint (on an object of a type)\v305.
     \vexplicitly specified by use of a qualification\v420.
     \vin a subtype indication in an allocator\v421.
     \vnot considered in overload resolution\v807.
     \von a derived subtype\v309.
     \von a formal parameter\v602.
     \von a formal parameter of a generic formal subprogram\v1204.
     \von a generic actual parameter\v1207.
     \von a generic formal object\v1202.
     \von a generic formal parameter\v1201.
     \von an object designated by an access value\v330.
     \von a renamed object\v805.
     \von a subcomponent subject to a component clause must be static\v1304.
     \von a subtype of a generic formal type\v1203.
     \von a type mark in a generic parameter declaration\v1207.
     \von a variable\v303.
     \von the result of a generic formal function\v1204.
\vCONSTRAINT_ERROR (predefined exception)\v1101.
     \vraised by an accept statement\v905.
     \vraised by an actual parameter not in the subtype of the formal\v607.
        \vparameter\v607.
     \vraised by an allocator\v421.
     \vraised by an assignment\v502.
     \vraised by an attribute\v315.
     \vraised by a component of an array aggregate\v409.
     \vraised by a component of a record aggregate\v408.
     \vraised by an entry call statement\v905.
     \vraised by a formal parameter not in the subtype of the actual\v607.
        \vparameter\v607.
     \vraised by an index value out of bounds\v402.
     \vraised by a logical operation on arrays of different lengths\v412.
     \vraised by a name with a prefix evaluated to a null access value\v401.
     \vraised by a qualification\v420.
     \vraised by a result of a conversion\v419.
     \vraised by a return statement\v509.
     \vraised by incompatible constraints\v307.
     \vraised by integer exponentiation with a negative exponent\v417.
     \vraised by matching failure in an array  assignment\v503.
     \vraised by naming of a variant not present in a record\v404.
     \vraised by the elaboration of a generic instantiation\v1207.
     \vraised by the initialization of an object\v303.
     \vraised by the result of catenation\v414.
\vContext clause\v1002.
     \vdetermining order of elaboration of compilation units\v1008.
     \vin a compilation unit\v1001.
     \vincluding a use clause\v804.
     \vinserted by the environment\v1007.
     \vof a subunit\v1004.
\vContext of overload resolution\v807.
\vCONTROLLED (predefined pragma)\v421.
\vConversion operation\v419.
     \vapplied to an undefined value\v303.
     \vas a basic operation\v308.
     \vbetween array types\v419.
     \vbetween numeric types\v308.
     \vfrom universal_ fixed type\v416.
     \vin a static expression\v422.
     \vof a universal type expression\v502.
     \vof the bounds of a loop parameter\v506.
     \vto a derived type\v309.
     \vto a real type\v418.
\vConvertible universal operand\v419.
\vCopy parameter passing\v602.
\vCOUNT (predefined attribute) for an entry\v912.
\vCOUNT (predefined integer type)\v1402.
CREATE (input-output procedure)
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
     \vraising an exception\v1419.
\vCurrent column number\v1408.
\vCurrent index of a direct access file\v1402.
\vCurrent line number\v1408.
\vCurrent mode of a file\v1401.
\vCurrent page number\v1408.
\vCurrent size of a direct access file\v1402.
\vCURRENT_INPUT (text_io function)\v1410.
\vCURRENT_OUTPUT (text_io function)\v1410.
\u- D -\n
\vDATA_ERROR (input-output exception)\v1419.
\vDAY (predefined function)\v906.
\vDecimal literal\v205.
     \vas a numeric literal\v204.
\vDecimal number text_io\v1415.
\vDeclaration\v301.
     \vas an overload resolution context\v807.
     \vdetermined by visibility from an identifier\v803.
     \vmade directly visible by a use clause\v804.
     \vof an enumeration literal\v311.
     \vof a formal parameter\v601.
     \vof a loop parameter\v506.
     \voverloaded\v610.
     \vraising an exception\v1106.
     \vto which a representation clause applies\v1301.
\vDeclarative item\v333.
     \vin a code procedure body\v1312.
     \vin a declarative part\v333.
     \vin a package specification\v605.
     \vin a visible part\v704.
     \vwhich is a use clause\v804.
\vDeclarative part\v333.
     \vin a block statement\v507.
     \vin a package body\v701.
     \vin a subprogram body\v603.
     \vin a task body\v901.
     \vincluding a generic declaration\v1205.
     \vincluding an inline pragma\v605.
     \vincluding an interface pragma\1313.
     \vincluding a representation clause\v1301.
     \vincluding a suppress pragma\v1109.
     \vincluding a task declaration\v903.
     \vwith implicit declarations\v501.
\vDeclarative region\v801.
     \vdetermining the visibility of a declaration\v803.
     \vformed by the predefined package standard\v806.
     \vin which a declaration is hidden\v803.
     \vincluding a full type definition\v706.
     \vincluding a subprogram declaration\v603.
\vDefault determination of a representation for an entity\v1301.
\uDefault expression\n
     \vcannot include a forcing occurrence\v1301.
     \vfor a component\v305.
     \vfor a component of a derived type object\v309.
     \vfor a discriminant\v326.
     \vfor a formal parameter\v601.
     \vfor a formal parameter of a generic formal subprogram\v1201.
     \vfor a formal parameter of a renamed subprogram or entry\v805.
     \vfor a generic formal object\v1201.
     \vfor the discriminants of an allocated object\v421.
     \vin a component declaration\v325.
     \vin a discriminant specification\v326.
     \vincluding the name of a private type\v326.
\vDefault file\v1410.
\vDefault generic formal subprogram\v1201.
\vDefault initial value (of a type)\v305.
     \vfor an access type object\v330.
     \vfor a record type object\v325.
\vDefault initialization (for an object)\v303.
\vDefault mode (of a file)\v1403.
\uDefault_aft (fiels length)\n
        \vof fixed_io or float_io\v1416.
\uDefault_base\n
     \vof integer_io\v1415.
\uDefault-exp (field length)\n
     \vof fixed_io or float_io\v1415.
\uDefault_fore (field length)\n
     \vof fixed_io or float_io\v1418.
\uDefault_setting (letter case)\n
     \vof enumeration_io\v1417.
\uDefault_width (field length)\n
     \vof enumeration_io\v1417.
     \vof integer_io\v1415.
\vDeferred constant\v707.
     \vof a limited type\v708.
\vDeferred constant declaration\v704.
     \vas a basic declaration\v301.
     \vcannot include a forcing occurrence\v1301.
\vDelay alternative (of a selective wait)\v908.
\vDelay expression\v906.
     \vin a timed entry call\v910.
\vDelay statement\v906.
     \vas a simple statement\v501.
     \vin an abnormal task\v913.
     \vin a select alternative\v908.
     \vin a timed entry call\v910.
\uDELETE (input-output procedure)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vDelimiter\v202.
\vDelta (of a fixed point type)\v319.
     \vof universal_fixed\v416.
\vDELTA (predefined attribute)\v320.
\vDenote an entity\v301.
\vDependence between compilation units\v1006.
     \vcircularity implying illegality\v1008.
\vDependence on a discriminant\v326.
     \vaffecting renaming\v805.
     \vby a subcomponent which is an actual parameter\v602.
     \veffect on compatibility\v327.
     \veffect on matching of components\v413.
     \vfor an assignment\v502.
\vDependent task\v904.
     \vdelaying exception propagation\v1105.
     \vof an abnormal task\v913.
\uDerivable subprogram\n
     \vprohibiting representation clauses\v1301.
\uDerived subprogram\n
     \vas an operation\v308.
     \vimplicitly declared\v308.
\vDerived type\v309.
     \vconversion to or from a parent type or related type\v419.
     \vof an access type designating a task type determining task\v904.
        \vdependence\v904.
     \vof a boolean type\v309.
     \vof a limited type\v708.
     \vof a private type\v705.
     \vsubject to a representation clause\v1301.
\vDerived type definition\v309.
\vDesignate\v330.
\vDesignated subtype (of an access type)\v330.
\vDesignated type (of an access type)\v330.
\vDesignator (of a function)\v601.
     \vin a function declaration\v411.
     \vin a subprogram body\v603.
     \vin a subprogram specification\v601.
     \vof a generic formal subprogram\v1212.
     \vof a library unit\v1001.
     \voverloaded\v610.
\vDEVICE_ERROR (input-output exception)\v1419.
\vDigit\v201.
     \vin a based literal\v206.
     \vin a decimal literal\v205.
     \vin an identifier\v203.
\vDigits (of a floating point type)\v317.
\vDIGITS (predefined attribute)\v318.
\vDimensionality of an array\v321.
\vDirect access file\v1402.
\vDirect input-output\v1406.
\vDirect visibility\v803.
     \vdue to a use clause\v804.
     \vof a library unit due to a with clause\v1002.
     \vwithin a subunit\v1004.
\vDIRECT_IO (predefined input-output generic package)\v1402.
     \vexceptions\v1419.
     \vspecification\v1407.
\vDiscrete range\v321.
     \vas a choice\v328.
     \vas a choice in an aggregate\v407.
     \vfor a loop parameter\v506.
     \vin a choice in a case statement\v505.
     \vin a generic formal array type declaration\v1203.
     \vin an index constraint\v321.
     \vin a loop parameter specification\v506.
     \vin a slice\v403.
     \vof entry indices in an entry declaration\v905.
\vDiscrete type\v310.
     \vas a generic actual parameter\v1209.
     \vas a generic formal type\v1203.
     \vexpression in a case statement\v505.
     \vof a discriminant\v326.
     \vof a loop parameter\v506.
     \vof index values of an array\v321.
     \voperation\v315.
\vDiscriminant\v305.
     \vin a record aggregate\v408.
     \vinitialization in an allocator constrains the allocated object\v421.
     \vof a formal parameter\v602.
     \vof a generic actual type\v1208.
     \vof a generic formal type\v1206.
     \vof an implicitly initialized object\v303.
     \vof an object designated by an access value\v327.
     \vof a private type\v706.
     \vof a variant part must not be of a generic formal type\v328.
     \vsimple name in a variant part\v328.
     \vsubcomponent of an object\v303.
     \vwith a default expression\v326.
\vDiscriminant association\v327.
     \vin a discriminant constraint\v327.
     \vnamed discriminant association\v327.
     \vnamed discriminant association for selective visibility\v803.
     \vpositional discriminant association\v327.
\vDiscriminant constraint\v327.
     \vignored due to access_check suppression\v1109.
     \vin an allocator\v421.
     \von an access type\v330.
     \vviolated\v1101.
\vDiscriminant part\v326.
     \vabsent from a record type declaration\v325.
     \vas a portion of a declarative region\v801.
     \vconforming to another\v801.
     \vin a generic formal type declaration\v326.
     \vin an incomplete type declaration\v331.
     \vin a private type declaration\v704.
     \vin a type declaration\v305.
     \vmay not include a pragma\v210.
     \vof a full type declaration is not elaborated\v306.
\vDiscriminant specification\v326.
     \vas part of a basic declaration\v301.
     \vdeclaring a component\v325.
     \vhaving an extended scope\v802.
     \vin a discriminant part\v326.
     \vvisibility\v803.
\uDivide\n
     \vcharacter\v201.
     \vdelimiter\v202.
\vDivision operation\v416.
     \vaccuracy for a real type\v418.
\uDot\n
     \vcharacter\v201.
     \vdelimiter\v202.
     \vdelimiter of a selected component\v803.
\vDouble dot compound delimiter\v202.
\vDouble hyphen starting a comment\v209.
\vDouble star compound delimiter\v202.
\vDURATION (predefined type)\v906.
     \vof alternative delay statements\v908.
\u- E -\n
\vELABORATE (predefined pragma)\v1008.
\vElaborated\v333.
\vElaboration\v333.
     \voptimized\v1009.
\vElaboration has no other effect\v301.
\uElaboration of\n
     \van access type definition\v330.
     \van array type definition\v321.
     \va body stub\v1004.
     \va component declaration\v325.
     \va component subtype definition\v325.
     \va constrained array definition\v321.
     \va declaration\v301.
     \va declarative item\v333.
     \va declarative part\v333.
     \va deferred constant declaration\v707.
     \va derived type definition\v309.
     \va discriminant constraint\v327.
     \va discriminant part\v326.
     \va discriminant specification\v326.
     \van entry declaration\v905.
     \van enumeration literal specification\v311.
     \van enumeration type definition\v311.
     \va fixed point type declaration\v319.
     \va floating point type declaration\v317.
     \va formal part\v601.
     \va full type declaration\v306.
     \va generic body\v1205.
     \va generic declaration\v1201.
     \va generic instantiation\v1206.
     \van incomplete type declaration\v331.
     \van index constraint\v322.
     \van integer type definition\v314.
     \va library unit\v1008.
     \va loop parameter specification\v506.
     \van object declaration\v303.
     \va package body\v703.
     \va package declaration\v702.
     \va parameter specification\v601.
     \va private type declaration\v705.
     \va range constraint\v310.
     \va real type definition\v316.
     \va record type definition\v325.
     \va renaming declaration\v805.
     \va representation clause\v1301.
     \va subprogram body\v603.
     \va subprogram declaration\v601.
     \va subtype declaration\v307.
     \va subtype indication\v307.
     \va task body\v901.
     \va task declaration\v901.
     \va task specification\v901.
     \va type declaration\v306.
     \va type definition \v306.
     \van unconstrained array definition\v321.
     \va use clause\v804.
\vElement in a file\v1400.
     \vin a direct access file\v1406.
     \vin a sequential access file\v1404.
\vELEMENT_TYPE (generic formal type of direct_io)\v1407.
\vELEMENT_TYPE (generic formal type of sequential_io)\v1405.
\uElse part\n
     \vof a conditional entry call\v909.
     \vof an if statement\v504.
     \vof a selective wait\v908.
\vEMAX (predefined attribute)\v318.
\vEmpty string literal\v208.
\vEnd of line\v202.
     \vas a separator\v202.
     \vdue to a format effector\v202.
     \vterminating a comment\v209.
\vEND_ERROR (input-output exception)\v1419.
END_OF_FILE (input-output function)
     \vin an instance of direct_io\v1402.
     \vin an instance of sequential_io\v1404.
     \vin text_io\v1409.
\vEND_OF_LINE (text_io function)\v1412.
     \vraising an exception\v1419.
\vEND_OF_PAGE (text_io function)\v1412.
\vEntry (of a task)\v905.
     \vdeclared by instantiation of a generic formal parameter\v1206.
     \vdenoted by an indexed component\v402.
     \vdenoted by a selected component\v404.
     \vname starting with a prefix\v401.
     \vof a derived task type\v309.
     \vof a task designated by an object of a task type\v905.
     \vrenamed\v805.
     \vsubject to an address clause\v1305.
     \vsubject to a representation clause\v1301.
\vEntry call\v905.
     \vto an abnormal task\v905.
     \vto communicate values\v914.
\vEntry call statement\v905.
     \vas a simple statement\v501.
     \vin an abnormal task\v913.
     \vin a conditional entry call\v909.
     \vin a timed entry call\v910.
\vEntry declaration\v905.
     \vas an overloaded declaration\v803.
     \vas part of a basic declaration\v301.
     \vcannot include a forcing occurrence\v1301.
     \vhaving an extended scope\v802.
     \vin a task specification\v901.
     \vincluding the name of a private type\v705.
     \vvisibility\v803.
\vEntry family\v905.
     \vdenoted by a selected component\v404.
     \vname starting with a prefix\v401.
\vEntry index (in the name of an entry of a family)\v905.
     \vfor an open accept alternative\v908.
     \vin a conditional entry call\v909.
     \vin a timed entry call\v910.
\vEntry queue (of calls awaiting acceptance)\v905.
     \vcount of calls in the queue\v909.
     \vdue to queued interrupts\v1306.
     \vof an abnormal task\v913.
\vEnumeration literal\v311.
     \vas an operation\v308.
     \vas an operator\v315.
     \vas result for image attribute\v315.
     \vas the parameter for value attribute\v315.
     \vimplicitly declared\v308.
     \vin a static expression\v422.
     \vin pragma system_name\v1308.
     \vof a derived type\v309.
     \voverloaded\v803.
     \vrenamed as a function\v805.
     \vrepresentation\v1303.
\vEnumeration literal specification\v311.
     \vas part of a basic declaration\v301.
     \vmade directly visible by a use clause\v804.
\vEnumeration representation clause\v1303.
     \vas a representation clause\v1301.
\vEnumeration type\v311.
     \vas a character type\v312.
     \vas a generic formal type\v1203.
     \vas a generic parameter\v1209.
     \vboolean\v313.
     \voperation\v315.
     \vsubject to an attribute\v315.
\vEnumeration type definition\v311.
\vENUMERATION_IO (text_io inner generic package)\v1417.
\vEnvironment of a program\v1007.
     \venvironment task calling the main program\v1001.
\vEPSILON (predefined attribute)\v318.
\uEqual\n
     \vcharacter\v201.
     \vdelimiter\v202.
\vEquality operator\v411.
     \vexplicitly declared\v413.
     \vfor an access type\v332.
     \vfor an array type\v323.
     \vfor a generic formal type\v1203.
     \vfor a limited type\v413.
     \vfor a real type\v418.
     \vfor a  record type\v329.
\vErroneous execution\v108.
     \vdue to an access to a deallocated object\v1315.
     \vdue to an unchecked conversion violating properties of objects of the\v1316.
        \vresult type\v1316.
     \vdue to assignment to a shared variable\v914.
     \vdue to changing of a discriminant value\v502.
     \vdue to independence on parameter-passing mechanism\v602.
     \vdue to multiple address clauses for overlaid entities\v1305.
     \vdue to suppression of an exception check\v1109.
     \vdue to use of an undefined value\v303.
\vError bounds of a predefined operation of a real type\v319.
\uError detected at\n
     \vcompilation time\v108.
     \vrun time\v108.
\vError situation\v108.
\vError that may not be detected\v108.
\vEvaluation (of an expression)\v411.
     \vat compile time\v422.
     \vof an actual parameter\v607.
     \vof an aggregate\v407.
     \vof an allocator\v421.
     \vof an array aggregate\v409.
     \vof a condition\v504.
     \vof a default expression\v327.
     \vof a default expression for a formal parameter\v608.
     \vof a discrete range\v310.
     \vof a discrete range used in an index constraint\v322.
     \vof an entry index\v905.
     \vof an expression in an assignment statement\v502.
     \vof an expression in a constraint\v307.
     \vof an expression in a generic actual parameter\v1206.
     \vof an indexed component\v402.
     \vof a literal\v406.
     \vof a logical operation\v412.
     \vof a name\v401.
     \vof a name in an abort statement\v913.
     \vof a name in a renaming declaration\v805.
     \vof a name of a variable\v502.
     \vof a primary\v410.
     \vof a qualified expression\v420.
     \vof a range\v310.
     \vof a record aggregate\v408.
     \vof a short circuit control form\v412.
     \vof a static expresion\v422.
     \vof a type conversion\v419.
     \vof a universal expression\v423.
     \vof the bounds of a loop parameter\v506.
     \vof the conditions of a selective wait\v908.
\vException\v1100.
     \vas an entity\v301.
     \vcausing a loop to be exited\v506.
     \vcausing a transfer of control\v501.
     \vdue to an expression evaluated at compile time\v1009.
     \vimplicitly declared in a generic instantiation\v1101.
     \vin input-output\v1419.
     \vrenamed\v805.
     \vsuppress pragma\v1109.
\vELABORATE (predefined pragma)\v1008.
\vException choice\v1102.
\vException declaration\v1101.
     \vas a basic declaration\v301.
\vException handler\v1102.
     \vin an abnormal task\v913.
     \vin a block statement\v507.
     \vin a package body\v701.
     \vin a subprogram body\v603.
     \vin a task body\v901.
     \vincluding a raise statement\v1103.
     \vincluding the destination of a goto statement\v510.
     \vincluding the name of an exception\v1101.
     \vnot allowed in a code procedure body\v1312.
     \vraising an exception\v1105.
     \vselected to handle an exception\v1105.
\vException handling\v1104.
\vException propagation\v1100.
     \vdelayed by a dependent task\v1105.
     \vfrom a declaration\v1106.
     \vfrom a predefined operation\v1108.
     \vfrom a statement\v1105.
     \vto a communicating task\v1107.
Exception raised during execution or elaboration of
     \van accept statement\v1107.
     \van allocator of a task\v903.
     \va conditional entry\v909.
     \va declaration\v1106.
     \va declarative part that declares tasks\v903.
     \va generic instantiation\v1207.
     \va selective wait\v908.
     \va subprogram call\v603.
     \va statement\v1105.
     \va subprogram call\v603.
     \va task\v1107.
     \vtask activation\v903.
     \va timed entry call\v910.
\vExceptions and optimization\v1108.
\vExclamation character\v201.
     \vreplacing vertical bar\v212.
\vExit statement\v508.
     \vas a simple statement\v501.
     \vcausing a loop to be exited\v506.
     \vcausing a transfer of control\v501.
     \vcompleting block statement execution\v904.
\vExpanded name\v404.
     \vdenoting a loop\v506.
     \vin a static expression\v422.
     \vof a parent unit\v1004.
     \vreplacing a simple name\v604.
\vExplicit conversion\v419.
  type conversion]
     \vfrom universal_fixed type\v416.
     \vto a real type\v418.
\vExplicit declaration\v301.
\vExponent of a floating point number\v317.
\uExponent part\n
     \vin output of real values\v1416.
     \vof a based literal\v205.
     \vof a decimal literal\v205.
\vExponentiating operator\v411.
     \vin a factor\v410.
     \voverloaded\v611.
\vExponentiation compound delimiter\v202.
\vExponentiation operation\v417.
\vExpression\v410.
     \vas an actual parameter\v606.
     \vas a condition\v504.
     \vas a generic actual parameter\v1206.
     \vas the argument of a pragma\v210.
     \vin an actual parameter of a conditional entry call\v909.
     \vin an actual parameter of an entry call statement\v905.
     \vin an actual parameter of a timed entry call\v910.
     \vin an allocator\v421.
     \vin an assignment statement\v502.
     \vin an attribute designator\v405.
     \vin a case statement\v505.
     \vin a choice in a case statement\v505.
     \vin a component association\v407.
     \vin a component declaration\v325.
     \vin a constraint\v307.
     \vin a conversion\v419.
     \vin a discriminant association\v327.
     \vin a discriminant specification\v326.
     \vin a generic formal part\v1201.
     \vin an indexed component\v402.
     \vin a length clause\v1302.
     \vin a name of a variable\v502.
     \vin a number declaration\v302.
     \vin an object declaration\v302.
     \vin a parameter specification\v601.
     \vin a primary\v410.
     \vin a qualified expression\v420.
     \vin a representation clause\v1301.
     \vin a return statement\v509.
     \vin a specification of a derived subprogram\v309.
     \vin a type conversion\v807.
     \vincluding the name of a private type\v705.
     \vspecifying an entry in a family\v402.
     \vspecifying the value of an index\v402.
     \vwith a boolean result\v412.
\vExtended_digit in a based literal\v206.
\vExternal file\v1401.
\u- F -\n
\vFactor\v410.
     \vin a term\v410.
\vFALSE boolean enumeration literal\v313.
\vFIELD (predefined integer subtype)\v1413.
\vFile (object of a file type)\v1401.
\vFile management\v1403.
     \vin text_io\v1409.
\vFile terminator\v1408.
\uFILE_MODE (input-output type)\n
     \vin an instance of direct_io\v1401.
     \vin an instance of sequential_io\v1401.
     \vin text_io\v1401.
\uFILE_TYPE (input-output type)\n
     \vin an instance of direct_io\v1401.
     \vin an instance of sequential_io\v1401.
     \vin text_io\v1401.
\vFIRST (predefined attribute)\v1500.
     \vfor an access value\v332.
     \vfor an array type\v323.
     \vfor a scalar type\v310.
\vFirst named subtype\v1301.
\vFIRST_BIT (predefined attribute)\v1310.
\vFixed accuracy definition\v319.
\vFixed point constraint\v319.
     \von a derived subtype\v309.
\vFixed point predefined types\v319.
\vFixed point types\v319.
     \vaccuracy of an operation\v418.
     \vas a generic actual type\v1209.
     \vas a generic formal type\v1203.
     \verror bounds\v418.
     \voperation\v320.
     \vresult of an operation out of range of the type\v418.
\vFIXED_IO (text_io inner generic package)\v1416.
\vFLOAT (predefined type)\v317.
\vFLOAT_IO (text_io inner generic package)\v1416.
\vFloating accuracy definition\v317.
\vFloating point constraint\v317.
     \von a derived subtype\v309.
\vFloating point types\v317.
     \vaccuracy of an operation\v418.
     \vas a generic actual type\v1209.
     \vas a generic formal type\v1203.
     \verror bounds\v418.
     \voperation\v318.
     \vresult of an operation out of range of the type\v418.
\vFont design of graphical symbols\v201.
\vForcing occurrence (of a name leading to default determination of\v1301.
  \vrepresentation)\v1301.
\vFORE (predefined attribute) for a fixed point type\v320.
\vFore field of text_io input or output\v1416.
\uFORM (input-output function)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
     \vraising an exception\v1419.
\vForm feed format effector\v201.
\vForm string of a file\v1401.
\vFormal parameter\v601.
  \v(of an entry)\v905.
  \v(of a function)\v609.
  \v(of an operator)\v611.
  \v(of a subprogram)\v601.
     \vas a constant\v303.
     \vas an object\v302.
     \vas a variable\v303.
     \vnames and overload resolution\v610.
     \vnames and overload resolution\v610.
     \vof a derived subprogram\v309.
     \vof a generic formal subprogram\v1201.
     \vof a main program\v1001.
     \vof an operation\v308.
     \vof a renamed entry or subprogram\v805.
     \vwhich is of an array type\v322.
     \vwhich is of a limited type\v708.
     \vwhich is of a record type\v327.
     \vwhich is of a task type\v902.
\vFormal part\v601.
     \vconforming to another\v604.
     \vin an accept statement\v905.
     \vin an entry declaration\v905.
     \vin a subprogram specification\v601.
     \vmust not include a pragma\v210.
\vFormat effector\v201.
     \vas a separator\v202.
     \vin an end of line\v202.
\vFormat of text_io input or output\v1413.
\vFrame\v1102.
     \vand optimization\v1108.
     \vin which an exception is raised\v1105.
\uFull declaration\n
     \vof a deferred constant\v707.
\vFull type declaration\v306.
     \vdiscriminant part is not elaborated\v306.
     \vof an incomplete type\v331.
     \vof a limited private type\v708.
     \vof a private type\v705.
\vFunction\v601.
     \vas a main program\v1001.
     \vrenamed\v805.
     \vthat is an attribute\v405.
\vFunction call\v606.
     \vas a prefix\v401.
     \vas a primary\v410.
     \vin a static expression\v422.
     \vwith a parameter of a derived type\v309.
     \vwith a result of a derived type\v309.
\u- G -\n
\vGarbage collection\v421.
\vGeneric actual object\v1207.
\vGeneric actual parameter\v1206.
     \vcannot be a universal_fixed operation\v416.
     \vfor a generic formal access type\v1211.
     \vfor a generic formal array type\v1210.
     \vfor a generic formal object\v1202.
     \vfor a generic formal private type\v1208.
     \vfor a generic formal scalar type\v1209.
     \vfor a generic formal subprogram\v1204.
     \vfor a generic formal type\v1203.
     \vis not static\v422.
     \vthat is an array aggregate\v409.
     \vthat is a loop parameter\v506.
     \vthat is a task type\v902.
\vGeneric actual part\v1206.
\vGeneric actual subprogram\v1204.
\uGeneric actual type\n
     \vfor a generic formal access type\v1211.
     \vfor a generic formal array type\v1210.
     \vfor a generic formal scalar type\v1209.
     \vfor a generic formal type with discriminants\v1208.
     \vfor a generic private formal type\v1208.
     \vthat is a private type\v705.
\vGeneric association\v1206.
     \vnamed generic association\v1206.
     \vnamed generic association for selective visibility\v803.
     \vpositional generic association\v1206.
\vGeneric body\v1205.
     \vin a package body\v701.
     \vincluding an exception handler\v1102.
     \vincluding an exit statement\v508.
     \vincluding a goto statement\v510.
     \vincluding an implicit declaration\v501.
     \vmust be in the same declarative part as the declaration\v333.
     \vnot yet elaborated at an instantiation\v333.
\vGeneric declaration\v1201.
     \vand body as a declarative region\v801.
     \vand proper body in the same compilation\v1006.
     \vas a basic declaration\v301.
     \vas a later declarative item\v333.
     \vas a library unit\v1001.
     \vin a package specification\v701.
     \vrecompiled\v1006.
\vGeneric formal object\v1201.
     \vof an array type\v322.
     \vof a record type\v327.
\vGeneric formal parameter\v1201.
     \vas a constant\v303.
     \vas a variable\v303.
     \vof a limited type\v708.
     \vof a task type\v902.
\vGeneric formal part\v1201.
\vGeneric formal subprogram\v1201.
     \vformal function\v1204.
     \vwith the same name as another\v1206.
\vGeneric formal type\v1201.
     \vas index or component type of a generic formal array type\v1210.
     \vdiscriminant must not be the discriminant of a variant\v328.
     \vformal access type\v1203.
     \vformal array type\v1203.
     \vformal array type (constrained)\v1203.
     \vformal discrete type\v1203.
     \vformal enumeration type\v1203.
     \vformal fixed point type\v1203.
     \vformal floating point type\v1203.
     \vformal integer type\v1203.
     \vformal limited private type\v1203.
     \vformal limited type\v1203.
     \vformal part\v1203.
     \vformal private type\v1203.
     \vformal private type with discriminants\v1208.
     \vformal scalar type\v1203.
\vGeneric instance\v1206.
     \vinlined in place of each call\v605.
     \vof a generic package\v1206.
     \vof a generic subprogram\v1206.
     \vraising an exception\v1105.
\vGeneric instantiation\v1206.
     \vas a basic declaration\v301.
     \vas a later declarative item\v333.
     \vas a library unit\v1001.
     \vbefore elaboration of the body\v333.
     \vimplicitly declaring an exception\v1101.
     \vinvoking an operation of a generic actual type\v1203.
     \vof a predefined input-output package\v1401.
     \vrecompiled\v1006.
     \vwith a formal access type\v1211.
     \vwith a formal array type\v1210.
     \vwith a formal scalar type\v1209.
     \vwith a formal subprogram\v1212.
\vGeneric package\v1201.
     \vfor input-output\v1400.
     \vinstantiation\v1206.
     \vspecification\v1201.
\vGeneric package body\v1205.
\vGeneric parameter declaration\v1201.
     \vas a declarative region\v801.
     \vhaving an extended scope\v802.
     \vvisibility\v803.
\vGeneric specification\v1201.
\vGeneric subprogram\v1201.
     \vbody\v1205.
     \vinstantiation\v1206.
     \vinterface pragma is not defined\v1313.
     \vspecification\v1201.
\vGeneric type definition\v1201.
\vGeneric unit\v1200.
     \vincluding an exception declaration\v1101.
     \vincluding a raise statement\v1103.
     \vsubject to a suppress pragma\v1109.
     \vwith a separately compiled body\v1004.
\vGET (text_io procedure)\v1413.
     \vfor character and string types\v1414.
     \vfor enumeration types\v1417.
     \vfor integer types\v1417.
     \vfor real types\v1416.
     \vraising an exception\v1419.
\vGET_LINE (text_io procedure)\v1414.
\vGlobal declaration\v801.
     \vof a variable shared by tasks\v914.
\vGoto statement\v510.
     \vas a simple statement\v501.
     \vcausing a loop to be exited\v506.
     \vcausing a transfer of control\v501.
     \vcompleting block statement execution\v904.
\vGraphic character\v201.
     \vin a character literal\v207.
     \vin a string literal\v208.
\vGraphical symbol\v201.
     \vnot available\v212.
\uGreater than\n
     \vcharacter\v201.
     \vdelimiter\v202.
\uGreater than or equal\n
     \vcompound delimiter\v202.
\u- H -\n
\vHandler\v1192.
\vHiding (of a declaration)\v803.
     \vand renaming\v805.
     \vand use clauses\v804.
     \vdue to an implicit declaration\v501.
     \vof a generic unit\v1201.
     \vof a library unit\v1001.
     \vof a subprogram\v610.
     \vof or by a derived subprogram\v309.
     \vof the package standard\v1001.
     \vwithin a subunit\v1004.
\vHighest precedence operator\v411.
     \vas an operation of a discrete type\v315.
     \vas an operation of a fixed point type\v320.
     \vas an operation of a floating point type\v318.
     \voverloaded\v611.
\vHomograph declaration\v803.
     \vand use clauses\v804.
\uHorizontal tabulation\n
     \vas a separator\v202.
     \vcharacter in a comment\v209.
     \vformat effector\v201.
     \vin text_io input\v1413.
\vHyphen character\v201.
     \vstarting a comment\v209.
\u- I -\n
\vIdentifier\v203.
     \vand an adjacent separator\v202.
     \vas an attribute designator\v405.
     \vas a designator\v601.
     \vas a reserved word\v211.
     \vas a simple name\v401.
     \vcan be written in the basic character set\v212.
     \vdenoting an object\v303.
     \vdenoting a value\v304.
     \vin a deferred constant declaration\v707.
     \vin an entry declaration\v905.
     \vin an exception declaration\v1101.
     \vin a generic instantiation\v1206.
     \vin an incomplete type declaration\v1312.
     \vin a number declaration\v304.
     \vin an object declaration\v302.
     \vin a package specification\v701.
     \vin a private type declaration\v704.
     \vin a renaming declaration\v805.
     \vin a subprogram specification\v601.
     \vin a task specification\v901.
     \vin a type declaration\v306.
     \vin its own declaration\v803.
     \vin pragma system_name\v1307.
     \vof an argument of a pragma\v210.
     \vof an enumeration value\v311.
     \vof a formal parameter of a generic formal subprogram\v1204.
     \vof a generic formal object\v1201.
     \vof a generic formal subprogram\v1201.
     \vof a generic formal type\v1201.
     \vof a generic unit\v1201.
     \vof a library unit\v1001.
     \vof a pragma\v210.
     \vof a subprogram\v601.
     \vof a subtype\v307.
     \vof a subunit\v1004.
     \vof homograph declarations\v803.
     \voverloaded\v610.
     \vversus simple name\v310.
\vIdentifier list\v302.
     \vin a component declaration\v325.
     \vin a deferred constant declaration\v704.
     \vin a discriminant specification\v326.
     \vin a generic parameter declaration for generic formal objects\v1201.
     \vin a number declaration\v302.
     \vin an object declaration\v302.
     \vin a parameter specification\v601.
\vIdentity operation\v415.
\vIf statement\v504.
     \vas a compound statement\v501.
\vIllegal\v108.
\vIMAGE (predefined attribute)\v315.
\vImmediate scope\v802.
\vImplementation defined pragma\v2000.
\vImplicit conversion\v419.
     \vof an integer literal to an integer type\v314.
     \vof a real literal to a real type\v316.
     \vof a universal expression\v314.
     \vof a universal real expression\v418.
\vImplicit declaration\v301.
     \vby a type declaration\v411.
     \vhidden by an explicit declaration\v803.
     \vof a basic operation\v301.
     \vof a block name, loop name, or label\v501.
     \vof a derived subprogram\v308.
     \vof an enumeration literal\v308.
     \vof an equality operator\v611.
     \vof an exception due to an instantiation\v1101.
     \vof a library unit\v806.
     \vof a predefined operator\v411.
     \vof universal_fixed operators\v416.
\uImplicit representation clause\n
     \vfor a derived type\v309.
\vIN_FILE (input-output file_mode enumeration literal)\v1401.
\vIncomplete type\v331.
     \vcorresponding full type declaration\v306.
\vIncomplete type declaration\v331.
     \vas a portion of a declarative region\v801.
\vIncorrect order dependence\v108.
     \vassignment statement\v502.
     \vbounds of a range constraint\v310.
     \vcomponent association of an array aggregate\v409.
     \vcomponent association of a record aggregate\v408.
     \vcomponent subtype indication\v321.
     \vdefault expression for a component\v303.
     \vdefault expression for a discriminant\v303.
     \vexpression\v411.
     \vindex constraint\v321.
     \vlibrary unit\v1008.
     \vparameter association\v606.
     \vprefix and discrete range of a slice\v403.
\vIndex\v321.
\uINDEX (input-output function)\n
     \vin an instance of direct_io\v1402.
\vIndex constraint\v321.
     \vignored due to index_check suppression\v1109.
     \vin an allocator\v421.
     \vin a constrained array definition\v321.
     \vin a subtype indication\v307.
     \von an access type\v330.
     \vviolated\v1101.
\vIndex of an element in a direct access file\v1402.
\vIndex range\v321.
     \vmatching\v413.
\vIndex subtype\v321.
\vIndex subtype definition\v321.
\uIndex type\n
     \vof a choice in an array aggregate\v409.
     \vof a generic formal array type\v1210.
\vIndexed component\v402.
     \vas a basic operation\v308.
     \vas a name\v401.
     \vas the name of an entry\v905.
     \vof a value of a generic formal array type\v1203.
\vInequality compound delimiter\v202.
\vInequality operation\v411.
     \vcannot be explicitly declared\v611.
     \vfor an access type\v332.
     \vfor an array type\v323.
     \vfor a generic formal type\v1203.
     \vfor a real type\v418.
     \vfor a real type\v418.
     \vnot available for a limited type\v708.
\vInitial value (of an object)\v303.
     \vin an allocator\v421.
     \vof an array object\v322.
     \vof a constant\v303.
     \vof a constant in a static expression\v422.
     \vof a discriminant of a formal parameter\v602.
     \vof a discriminant of an object\v327.
     \vof a limited private type object\v708.
     \vof an object declared in a package\v701.
     \vof an out mode formal parameter\v602.
     \vof a record object\v327.
\vINLINE (predefined pragma)\v605.
     \vcreating recompilation dependence\v1006.
\vINOUT_FILE (input-output file_mode enumeration literal)\v1401.
\vInput-output\v1400.
     \vat device level\v1421.
     \vexceptions\v1419.
     \vwith a direct access file\v1406.
     \vwith a sequential file\v1404.
     \vwith a text file\v1408.
\vINTEGER (predefined type)\v314.
     \vas base type of a loop parameter\v506.
     \vas default type for the bounds of a discrete range\v322.
\vInteger literal\v204.
     \vas a bound of a discrete range\v905.
     \vas a universal integer literal\v314.
     \vin based notation\v206.
     \vin decimal notation\v205.
\uInteger part\n
     \vas a base of a based literal\v206.
     \vof a decimal literal\v205.
\vInteger predefined type\v314.
\uInteger subtype\n
     \vdue to an integer type definition\v314.
\vInteger type\v314.
     \vas a generic formal type\v1203.
     \vas a generic parameter\v1209.
     \voperation\v315.
     \vresult of a conversion from a numeric type\v419.
     \vresult of an operation out of range of the type\v411.
\vInteger type definition\v314.
\vINTEGER_IO (text_io inner generic package)\v1414.
\vINTERFACE (predefined pragma)\v1313.
\vInterface to other languages\v1313.
\vInterrupt\v1305.
\vInterrupt entry\v1306.
\vIO_EXCEPTIONS (predefined input-output package)\v1419.
     \vspecification\v1420.
IS_OPEN (input-output function)
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vISO (international organization for standardization)\v201.
\vISO seven bit coded character set\v201.
\vIteration scheme\v506.
\u- L -\n
\vLabel\v501.
     \vdeclaration\v501.
     \vimplicitly declared\v301.
     \vlead to by a goto statement\v510.
\uLabel bracket\n
     \vcompound delimiter\v202.
\vLabeled statement\v501.
     \vin a code statement\v1312.
\vLARGE (predefined attribute)\v318.
\vLAST (predefined attribute)\v1500.
     \vfor an access value\v332.
     \vfor an array type\v323.
     \vfor a scalar type\v310.
\vLAST_BIT (predefined attribute)\v1310.
\vLater declarative item\v333.
\vLAYOUT_ERROR (input-output exception)\v1419.
\vLeading zeros in a numeric literal\v205.
\vLeft label bracket compound delimiter\v202.
\uLeft parenthesis\n
     \vcharacter\v201.
     \vdelimiter\v202.
\vLegal\v108.
\vLENGTH (predefined attribute)\v323.
     \vfor an access value\v332.
\vLength clause\v1302.
     \vas a representation clause\v1301.
     \vfor an access type\v421.
     \vspecifying small of a fixed point type\v1302.
\vLength of a string literal\v208.
Length of the result
     \vof an array comparison\v412.
     \vof an array logical negation\v417.
     \vof a catenation\v414.
\uLess than\n
     \vcharacter\v201.
     \vdelimiter\v202.
\uLess than or equal\n
     \vcompound delimiter\v202.
\vLetter\v203.
     \ve or E in a decimal literal\v205.
     \vin a based literal\v206.
     \vin an identifier\v203.
\vLetter_or_digit\v203.
\vLexical element\v200.
     \vas a point in the program text\v803.
     \vin a conforming construct\v604.
     \vtransferred by a text_io procedure\v1408.
\vLexicographic order\v413.
\uLibrary package\n
     \vhaving dependent tasks\v904.
\uLibrary package body\n
     \vraising an exception\v1105.
\vLibrary unit\v1001.
     \vcompiled before the corresponding body\v1006.
     \vfollowed by an inline pragma\v605.
     \vincluded in the predefined package standard\v806.
     \vmay not be subject to an address clause\v1305.
     \vnamed in a use clause\v1008.
     \vnamed in a with clause\v1002.
     \vrecompiled\v1006.
     \vscope\v802.
     \vsubject to an interface pragma\v1313.
     \vthat is a package\v701.
     \vvisibility due to a with clause\v803.
     \vwhose name is needed in a compilation unit\v1002.
     \vwith a body stub\v1004.
\vLimited private type\v708.
     \vas a generic actual type\v1208.
     \vas a generic formal type\v1203.
\vLimited type\v708.
     \vas a full type\v705.
     \vcomponent of a record\v325.
     \vgeneric formal object\v1202.
     \vin an object declaration\v303.
     \vlimited record type\v329.
     \voperation\v329.
     \vparameters for explicitly declared equality operators\v611.
\vLine\v1408.
\vLINE (text_io function)\v1412.
     \vraising an exception\v1419.
\vLine feed format effector\v201.
\vLine length\v1408.
\vLine terminator\v1408.
\vLINE_LENGTH (text_io function)\v1411.
     \vraising an exception\v1419.
\vLIST (predefined pragma)\v1600.
\vLiteral\v406.
     \vas a basic operation\v308.
     \vof a derived type\v309.
     \vof universal_integer type\v314.
     \vof universal_real type\v314.
\vLocal declaration\v801.
     \vin a generic unit\v1206.
\vLogical negation operation\v417.
\vLogical operation\v412.
\vLogical operator\v411.
     \vas an operation of boolean type\v315.
     \vfor an array type\v323.
     \vin an expression\v410.
     \voverloaded\v611.
\vLogical processor\v900.
\vLONG_FLOAT (predefined type)\v317.
\vLONG_INTEGER (predefined type)\v314.
\vLoop name\v506.
     \vdeclaration\v501.
     \vimplicitly declared\v301.
     \vin an exit statement\v508.
\vLoop parameter\v506.
     \vas an object\v302.
\vLoop parameter specification\v506.
     \vas an overload resolution context\v807.
     \vis a declaration\v301.
\vLoop statement\v506.
     \vas a compound statement\v501.
     \vas a declarative region\v801.
     \ventity denoted by an expanded name\v404.
     \vincluding an exit statement\v508.
\vLOW_LEVEL_IO (predefined input-output package)\v1421.
\vLower case letter\v201.
     \va to f in a based literal\v206.
     \ve in a decimal literal\v205.
     \vin an identifier\v203.
\u- M -\n
\vMachine code insertion\v1312.
\vMachine dependent attribute\v1311.
\vMACHINE_CODE (predefined package)\v1312.
\vMACHINE_EMAX (predefined attribute)\v1311.
\vMACHINE_EMIN (predefined attribute)\v1311.
\vMACHINE_MANTISSA (predefined attribute)\v1311.
\vMACHINE_OVERFLOWS (predefined attribute)\v1311.
\vMACHINE_RADIX (predefined attribute)\v1311.
\vMACHINE_ROUNDS (predefined attribute)\v1311.
\vMain program\v1001.
     \vexecution requiring elaboration of library units\v1008.
     \vincluded in the predefined package standard\v806.
     \vincluding a priority pragma\v911.
     \vraising an exception\v1105.
     \vtermination\v904.
\vMANTISSA (predefined attribute)\v318.
\uMantissa\n
     \vof a fixed point number\v319.
     \vof a floating point number\v317.
\vMaster (task)\v904.
\uMatching components\n
     \vof arrays\v413.
     \vof records\v413.
\uMatching generic formal\n
     \vand actual parameters\v1206.
     \vaccess type\v1211.
     \varray type\v1210.
     \vdefault subprogram\v1212.
     \vobject\v1207.
     \vprivate type\v1208.
     \vscalar type\v1209.
     \vsubprogram\v1212.
     \vtype\v1208.
\vMathematically correct result of a numeric operation\v411.
\vMaximum line length\v1408.
\vMaximum page length\v1408.
\vMembership test\v410.
     \vcannot be overloaded\v611.
\vMembership test operation\v411.
     \vas a basic operation\v308.
     \vfor a real type\v418.
\vMEMORY_SIZE (predefined pragma)\v1308.
\uMinus\n
     \vcharacter in an exponent of a numeric literal\v205.
     \vdelimiter\v202.
     \vunary operation\v415.
\uMODE (input-output function)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vMode (of a file)\v1401.
     \vof a direct access file\v1402.
     \vof a sequential access file\v1402.
     \vof a text_io file\v1409.
\vMode (of a parameter)\v602.
     \vof a formal parameter of a derived subprogram\v309.
     \vof a formal parameter of a renamed entry or subprogram\v805.
     \vof a generic form object\v1202.
\vMode in out for a formal parameter\v601.
     \vof a function\v609.
     \vof an interrupt entry\v1306.
\vMode in for a generic formal object\v1202.
\vMode in for a formal parameter\v601.
     \vof a function is not allowed\v609.
     \vof an interrupt entry is not allowed\v1306.
\vMode in out for a generic formal object\v1202.
\vMode out for a formal parameter\v601.
     \vof a function is not allowed\v609.
     \vof an interrupt entry is not allowed\v1306.
\vMODE_ERROR (input-output exception)\v1419.
\vModel interval of a subtype\v418.
\vModel number (of a real type)\v316.
     \vaccuracy of a real operation\v418.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
\vModulus operation\v416.
\vMONTH (predefined function)\v906.
\vMultidimensional array\v321.
\uMultiple\n
     \vcomponent definition\v325.
     \vdeferred constant declaration\v704.
     \vdiscriminant specification\v326.
     \vgeneric parameter declaration\v1201.
     \vnumber declaration\v304.
     \vobject declaration\v601.
     \vparameter specification\v601.
\vMultiplication operation\v416.
     \vaccuracy for a real type\v418.
\vMultiplying operator\v411.
     \vin a term\v410.
     \voverloaded\v611.
\vMust (legality requirement)\v108.
\vMutually recursive types\v331.
\u- N -\n
\uNAME (input-output function)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vName (of an entity)\v401.
     \vas a prefix\v401.
     \vas a primary\v410.
     \vas the argument of a pragma\v210.
     \vas the expression in a case statement\v505.
     \vconflicts\v805.
     \vdeclared by renaming is not allowed as prefix of certain expanded\v404.
        \vnames\v404.
     \vdeclared in a generic unit\v1206.
     \vdenoting an entity\v401.
     \vdenoting an object designated by an access value\v401.
     \vstarting with a prefix\v401.
\vName string (of a file)\v1401.
\vNAME_ERROR (input-output exception)\v1419.
\vNamed association\v608.
\vNamed number\v302.
     \vas an entity\v301.
     \vas a primary\v410.
     \vin a static expression\v422.
\vNATURAL (predefined integer subtype)\v1700.
\vNegation operation (numeric)\v415.
\uNegative exponent\n
     \vin a numeric literal\v205.
     \vto an exponentiation operator\v417.
\vNEW_LINE (text_io procedure)\v1412.
     \vraising an exception\v1419.
\vNEW_PAGE (text_io procedure)\v1412.
     \vraising an exception\v1419.
\uNot unary operator\n
     \vas an operation of an array type\v323.
     \vas an operation of boolean type\v315.
     \vin a factor\v410.
\vNot yet elaborated\v333.
\vNull access value\v330.
     \vcausing constraint_error\v410.
     \vnot causing constraint_error\v1109.
\vNull array\v322.
     \vaggregate\v409.
     \vand relational operation\v413.
     \vas an operand of a catenation\v414.
\vNull component list\v325.
\vNull literal\v330.
     \vas a basic operation\v308.
     \vas a primary\v410.
     \vmust not be the argument of a conversion\v419.
\vNull range\v310.
     \vas a choice of a variant part\v328.
     \vfor a loop parameter\v506.
\vNull record\v325.
     \vand relational operation\v413.
\vNull slice\v403.
\vNull statement\v501.
     \vas a simple statement\v501.
\vNull string literal\v208.
\vNumber declaration\v302.
     \vas a basic declaration\v301.
\vNUMBER_BASE (predefined integer subtype)\v1415.
\vNumeric literal\v204.
     \vand an adjacent separator\v202.
     \vas a basic operation\v308.
     \vas a primary\v410.
     \vas the parameter of value attribute\v315.
     \vas the result of image attribute\v315.
     \vassigned\v502.
     \vcan be written in the basic character set\v212.
     \vin a conforming construct\v604.
     \vin a static expression\v422.
     \vin pragma memory_size\v1308.
     \vin pragma storage_unit\v1308.
\vNumeric operation of a universal type\v423.
\vNumeric type\v310.
     \voperation\v411.
\uNumeric type expression\n
     \vin a length clause\v1302.
\vNumeric value of a number declaration\v302.
\vNUMERIC_ERROR (predefined exception)\v1101.
     \vnot raised due to lost overflow conditions\v1315.
     \vnot raised due to optimization\v1108.
     \vraised by a numeric operator\v411.
     \vraised by a predefined integer operation\v314.
     \vraised by a real result out of range of the safe numbers\v418.
     \vraised by a universal expression\v423.
     \vraised by integer division remainder or modulus\v416.
     \vraised due to a conversion out of range\v314.
\u- O -\n
\vObject\v302.
     \vas an actual parameter\v602.
     \vas a generic formal parameter\v1202.
     \vcreated by an allocator\v421.
     \vcreated by elaboration of an object declaration\v303.
     \vrenamed\v805.
     \vsubject to an address clause\v1305.
     \vsubject to a representation clause\v1301.
     \vsubject to a suppress pragma\v1109.
\vObject declaration\v302.
     \vas a basic declaration\v301.
     \vas a full declaration\v707.
     \vimplied by a task declaration\v901.
     \vin a package specification\v701.
     \vof an array object\v322.
     \vof a record object\v327.
     \vwith a limited type\v708.
     \vwith a task type\v902.
\uObject designated\n
     \vby an access value\v302.
     \vby an access value denoted by a name\v401.
     \vby an access-to-array type\v322.
     \vby an access-to-record type\v327.
     \vby a generic formal access type value\v1211.
\uObject module\n
     \vfor a subprogram written in another language\v1313.
\vObsolete compilation unit (due to recompilation)\v1006.
\vOccur immediately within (a declarative region)\v801.
\vOmitted parameter association for a subprogram call\v608.
\uOPEN (input-output procedure)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
     \vraising an exception\v1419.
\vOpen alternative\v908.
     \vaccepting a conditional entry call\v909.
     \vaccepting a timed entry call\v910.
\vOpen file\v1401.
\vOperation\v305.
     \vclassification\v308.
     \vof an access type\v332.
     \vof an array type\v323.
     \vof a discrete type\v315.
     \vof a fixed point type\v320.
     \vof a floating point type\v318.
     \vof a generic actual type\v1203.
     \vof a generic formal type\v1203.
     \vof a limited type\v708.
     \vof a private type\v706.
     \vof a record type\v329.
     \vof a subtype\v305.
     \vof a subtype of a discrete type\v315.
     \vof a type\v305.
     \vof a universal type\v423.
     \vpropagating an exception\v1108.
     \vsubject to a suppress pragma\v1109.
\vOperator\v411.
     \vas an operation\v308.
     \vimplicitly declared\v308.
     \vin an expression\v410.
     \vin a static expression\v422.
     \vof a derived type\v309.
     \vof a generic actual type\v1203.
     \voverloaded\v611.
     \vrenamed\v805.
\vOperator declaration\v601.
\vOperator symbol\v601.
     \vas a designator\v601.
     \vas a designator in a function declaration\v411.
     \vas a name\v401.
     \vbefore arrow compound delimiter\v803.
     \vdeclared\v301.
     \vdeclared in a generic unit\v1206.
     \vin a renaming declaration\v805.
     \vin a selector\v404.
     \vin a static expression\v422.
     \vnot allowed as the designator of a library unit\v1001.
     \vof a generic formal function\v1204.
     \vof homograph declarations\v803.
     \voverloaded\v611.
\vOptimization\v1009.
     \vand exceptions\v1108.
\vOPTIMIZE (predefined pragma)\v1600.
\vOrder of application of operators in an expression\v411.
\vOrder of compilation (of compilation units)\v1001.
        \vcreating recompilation dependence\v1006.
\vOrder of copying back of out and in out formal parameters\v606.
\vOrder of elaboration\v333.
  \v(of compilation units)\v1008.
\vOrder of evaluation\v108.
     \vand exceptions\v1108.
     \vof conditions in an if statement\v504.
     \vof default expressions for components\v303.
     \vof expressions and the name in an assignment statement\v502.
     \vof operands in an expression\v411.
     \vof parameter associations in a subroutine call\v606.
     \vof the bounds of a range\v310.
     \vof the conditions in a selective wait\v908.
\vOrdering operator\v411.
\vOrdering relation\v413.
     \vfor a real type\v418.
     \vof an enumeration type preserved by a representation clause\v1303.
     \vof a scalar type\v310.
\vOther special character\v210.
\vOthers\v328.
     \vas a choice in an array aggregate\v409.
     \vas a choice in a case statement alternative\v505.
     \vas a choice in a component association\v407.
     \vas a choice in a record aggregate\v408.
     \vas a choice in a variant part\v328.
     \vas an exception choice\v1102.
\vOUT_FILE (input-output file_mode enumeration literal)\v1401.
\vOverflow of real operations\v418.
\vOverlapping slices in array assignment\v503.
\vOverlaying of objects or program units\v1305.
\vOverloading\v803.
     \vand visibility\v803.
     \vin an assignment statement\v502.
     \vin an expression\v410.
     \vresolution\v610.
     \vresolution context\v807.
     \vresolved by explicit qualification\v420.
\uOverloading of\n
     \van aggregate\v309.
     \van allocator\v421.
     \va declaration\v803.
     \va designator\v610.
     \van entry\v905.
     \van enumeration literal\v311.
     \va generic formal subprogram\v1206.
     \va generic unit\v1201.
     \van identifier\v610.
     \va library unit by a locally declared subprogram\v1001.
     \va library unit by means of renaming\v1001.
     \va literal\v406.
     \va membership test\v413.
     \van operator\v411.
     \van operator symbol\v610.
     \va subprogram\v610.
     \va subprogram subject to an interface pragma\v1313.
     \vthe expression in a case statement\v505.
\u- P -\n
\vPACK (predefined pragma)\v1301.
\vPackage\v700.
     \vas a generic instance\v1206.
     \vincluding a raise statement\v1103.
     \vnamed in a use clause\v804.
     \vrenamed\v805.
     \vsubject to an address clause\v1305.
     \vsubject to representation clause\v1301.
     \vwith a separately compiled body\v1004.
\vPackage body\v701.
     \vas a generic body\v1205.
     \vas a proper body\v333.
     \vas a secondary unit\v1001.
     \vas a secondary unit compiled after the corresponding library unit\v1006.
     \vin another package body\v701.
     \vincluding an exception handler\v1102.
     \vincluding an exit statement\v508.
     \vincluding a goto statement\v510.
     \vincluding an implicit declaration\v501.
     \vmust be in the same declarative part as the declaration\v333.
     \vraising an exception\v1105.
     \vrecompiled\v1006.
     \vsubject to a suppress pragma\v1109.
\vPackage declaration\v701.
     \vand body as a declarative region\v801.
     \vas a basic declaration\v301.
     \vas a later declarative item\v333.
     \vas a library unit\v1001.
     \vdetermining the visibility of another declaration\v803.
     \velaboration raising an exception\v1106.
     \vin a package specification\v701.
     \vrecompiled\v1006.
\vPackage identifier\v701.
\vPackage specification\v701.
     \vin a generic declaration\v1201.
     \vincluding an inline pragma\v605.
     \vincluding an interface pragma\v1313.
     \vincluding a representation clause\v1301.
     \vincluding a suppress pragma\v1109.
\vPage\v1412.
\vPAGE (predefined pragma)\v1600.
\vPAGE  (text_io function)\v1411.
     \vraising an exception\v1419.
\vPage length\v1408.
\vPage terminator\v1408.
\vPAGE_LENGTH (text_io function)\v1411.
     \vraising an exception\v1419.
\vParagraphing recommended for the layout of programs\v107.
\vParameter\v1800.
     \vof a main program\v1001.
\vParameter and result type profile\v610.
\vParameter association\v606.
     \vfor a derived subprogram\v309.
     \vnamed parameter association\v606.
     \vnamed parameter association for selective visibility\v803.
     \vomitted for a subprogram call\v608.
     \vpositional parameter association\v606.
\vParameter specification\v601.
     \vas part of a basic declaration\v301.
     \vhaving an extended scope\v802.
     \vin a formal part\v601.
     \vvisibility\v803.
\vParameter type profile\v610.
\vParent subprogram (of a derived subprogram)\v309.
\vParent subtype (of a derived subtype)\v309.
\vParent type (of a derived type)\v309.
     \vdeclared in a visible part\v309.
     \vof a generic actual type\v1203.
     \vof a numeric type is predefined and anonymous\v314.
\vParent unit (of a body stub)\v1004.
     \vcompiled before its subunits\v1006.
\uParenthesis\n
     \vcharacter\v201.
     \vdelimiter\v202.
\uParenthesized expression\n
     \vas a primary\v410.
     \vin a static expression\v422.
\vPartial ordering of compilation\v1006.
\vPercent character\v201.
     \vreplacing quotation character\v212.
\vPeriod character\v201.
\vPhysical processor\v900.
\uPlus\n
     \vcharacter\v201.
     \vdelimiter\v202.
     \vunary operation\v415.
\vPoint character\v201.
     \vin a based literal\v206.
     \vin a decimal literal\v205.
     \vin a numeric literal\v204.
\vPoint delimiter\v202.
\vPortability\v101.
  \vof programs using real types\v1311.
\vPOS (predefined attribute)\v315.
\vPOSITION (predefined attribute)\v1310.
Position number
     \vas parameter to val attribute\v315.
     \vof an enumeration literal\v311.
     \vof an integer value\v314.
     \vof a value of a discrete type\v310.
     \vreturned by pos attribute\v315.
\vPosition of an element in a direct access file\v1402.
\vPositional association\v606.
\vPOSITIVE (predefined integer subtype)\v324.
     \vas the index type of the string type\v324.
\vPOSITIVE_COUNT (predefined integer subtype)\v1407.
\vPotentially visible declaration\v804.
\vPound sterling character\v201.
\vPragma\v210.
     \vapplicable to the whole of a compilation\v1001.
     \vargument that is an overloaded subprogram name\v323.
     \vfor the specification of a subprogram body in another language\v1313.
     \vfor the specification of program overlays\v1305.
     \vin a code procedure body\v1312.
     \vrecommending the representation of an entity\v1301.
     \vspecifying implementation conventions for code statements\v1312.
\uPragma (predefined)\n
     \vCONTROLLED\v421.
     \vELABORATE\v1008.
     \vINLINE\v605.
     \vINTERFACE\v1313.
     \vLIST\v1600.
     \vMEMORY_SIZE\v1308.
     \vOPTIMIZE\v1600.
     \vPACK\v1301.
     \vPAGE\v1600.
     \vPRIORITY\v911.
     \vSHARED\v914.
     \vSTORAGE_UNIT\v1308.
     \vSUPPRESS\v1109.
     \vSYSTEM_NAME\v1308.
\vPrecedence\v411.
\vPRED (predefined attribute)\v315.
\vPredefined constant\v806.
\vPredefined exception\v806.
\vPredefined function\v806.
\vPredefined generic library function\v806.
\vPredefined generic library package\v806.
\vPredefined generic library procedure\v806.
\vPredefined generic library subprogram\v806.
\vPredefined identifier\v806.
\vPredefined library package\v806.
\vPredefined operation\v305.
     \vaccuracy for a real type\v418.
     \vof a discrete type\v315.
     \vof a fixed point type\v320.
     \vof a universal type\v423.
     \vpropagating an exception\v1108.
\vPredefined operator\v411.
     \vapplied to an undefined value\v303.
     \vas an operation\v308.
     \vfor an access type\v332.
     \vfor an array type\v323.
     \vfor a record type\v329.
     \vimplicitly declared\v308.
     \vin a static expression\v422.
     \vof a derived type\v309.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
     \vof an integer type\v314.
     \vraising an exception\v1105.
\vPredefined package\v806.
     \vfor input-output\v1400.
\vPredefined subprogram\v806.
\vPredefined subtype\v806.
\vPredefined type\v806.
\vPrefix\v401.
     \vin an attribute\v405.
     \vin an indexed component\v402.
     \vin a selected component\v404.
     \vin a slice\v403.
     \vthat is a function call\v401.
     \vthat is a name\v401.
\vPrimary\v410.
     \vin a factor\v410.
     \vin a static expression\v422.
\vPRIORITY (predefined integer subtype)\v911.
\vPRIORITY (predefined pragma)\v911.
\vPrivate part (of a package)\v702.
\vPrivate type\v305.
     \vas a generic actual type\v1208.
     \vas a generic formal type\v1203.
     \vas a parent type\v309.
     \vcorresponding full type declaration\v306.
     \vformal parameter\v602.
     \vof a deferred constant\v704.
     \voperation\v706.
\vPrivate type declaration\v704.
     \vas a generic type declaration\v1201.
     \vas a portion of a declarative region\v801.
     \vincluding the word 'limited'\v708.
\vProcedure\v601.
     \vas a main program\v1001.
     \vas a renaming of an entry\v905.
     \vrenamed\v805.
\uProcedure body\n
     \vincluding code statements\v1312.
\vProcedure call\v606.
\vProcedure call statement\v606.
     \vas a simple statement\v501.
     \vwith a parameter of a derived type\v309.
\vProcessor\v900.
\vProgram\v1000.
\vProgram legality\v108.
\vProgram library\v1001.
     \vcreation\v1007.
     \vmanipulation and status\v1007.
\vProgram optimization\v1008.
\vProgram text\v202.
\vProgram unit\v600.
     \ventity denoted by an expanded name\v404.
     \vincluding a suppress pragma\v1109.
     \vsubject to an address clause\v1305.
     \vwith a separately compiled body\v1004.
\vPROGRAM_ERROR (predefined exception)\v1101.
     \vraised by an erroneous program or incorrect order dependence\v108.
     \vraised by a generic instantiation before elaboration of the body\v333.
     \vraised by a subprogram call before elaboration of the body\v333.
     \vraised by a task activation before elaboration of the body\v333.
     \vraised by reaching the end of a function body\v609.
\vProper body\v333.
     \vas a body\v333.
     \vin a subunit\v1004.
     \vof a library unit separately compiled\v1001.
\vPUT (text_io procedure)\v1408.
     \vfor character and string types\v1414.
     \vfor enumeration types\v1417.
     \vfor integer types\v1415.
     \vfor real types\v1416.
     \vraising an exception\v1419.
\u- Q -\n
\vQualification\v420.
     \vas a basic operation\v308.
     \vusing a name of an enumeration type as qualifier\v311.
\vQualified expression\v420.
     \vas a primary\v410.
     \vin an allocator\v421.
     \vin a case statement\v505.
     \vin a static expression\v422.
     \vqualification of an array aggregate\v409.
     \vto resolve an overloading ambiguity\v610.
\vQuotation character\v201.
     \vin a string literal\v208.
     \vreplacement by percent character\v212.
\u- R -\n
\vRadix of a floating point type\v317.
\vRaise statement\v1103.
     \vas a simple statement\v501.
     \vincluding the name of an exception\v1101.
\vRaising of an exception\v1100.
     \vcausing a transfer of control\v501.
\vRange\v310.
     \vas a discrete range\v321.
     \vin a record representation clause\v1304.
     \vin a relation\v410.
     \vof an index subtype\v321.
     \vof an integer type containing the result of an operation\v411.
     \vof a predefined integer type\v314.
     \vof a real type containing the result of an operation\v418.
     \vyielded by an attribute\v405.
\vRANGE (predefined attribute)\v323.
     \vfor an access value\v332.
     \vfor an array type\v323.
\vRange constraint\v310.
     \vignored due to range_check suppression\v1109.
     \vin a fixed point constraint\v319.
     \vin a floating point constraint\v317.
     \vin an integer type definition\v314.
     \vin a subtype indication\v310.
     \von a derived subtype\v309.
     \vviolated\v1101.
\uREAD (input-output procedure)\n
     \vin an instance of direct_io\v1406.
     \vin an instance of sequential_io\v1404.
\vReading the value of an object\v602.
\vReal literal\v204.
     \vin based notation\v206.
     \vin decimal notation\v205.
     \vis of universal_real type\v316.
\vReal type\v316.
     \vaccuracy of an operation\v418.
     \vrepresentation attribute\v1311.
     \vresult of a conversion from a numeric type\v418.
     \vresult of an operation out of range of the type\v411.
\vReal type definition\v316.
\vRECEIVE_CONTROL (low_level_io procedure)\v1421.
\vReciprocal operation in exponentiation by a negative integer\v417.
\vRecompilation\v1006.
\vRecord aggregate\v408.
     \vas a basic operation\v308.
     \vin a code statement\v1312.
\vRecord representation clause\v1304.
     \vas a representation clause\v1301.
\vRecord type\v325.
     \vformal parameter\v602.
     \vincluding a limited subcomponent\v708.
     \voperation\v329.
\uRecord type declaration\n
     \vas a declarative region\v801.
     \vdetermining the visibility of another declaration\v803.
\vRecord type definition\v307.
\uRecursive\n
     \vcall of a subprogram\v601.
     \vgeneric instantiation\v1201.
     \vtypes\v331.
\vReentrant subprogram\v601.
\vReference (parameter passing)\v602.
\vRelation (in an expression)\v410.
\vRelational operation\v413.
     \vof a boolean type\v313.
     \vof a discrete type\v315.
     \vof a fixed point type\v320.
     \vof a real type\v418.
     \vof a scalar type\v310.
     \vresult for real operands\v418.
\vRelational operator\v411.
     \vfor an access type\v332.
     \vfor an array type\v323.
     \vfor a private type\v706.
     \vfor a record type\v329.
     \vfor time predefined type\v906.
     \vin a relation\v410.
     \voverloaded\v611.
\vRem operator\v416.
\vRemainder operation\v416.
\vRenaming declaration\v805.
     \vas a basic declaration\v301.
     \vas a declarative region\v801.
     \vcannot rename a universal_fixed operation\v416.
     \vfor an array object\v322.
     \vfor an entry\v905.
     \vfor a record object\v327.
     \vname declared is not allowed as a prefix of certain expanded names\v404.
     \vto overload a library unit\v1001.
     \vto overload a subunit\v1002.
     \vto resolve an overloading ambiguity\v610.
\vRendezvous (of tasks)\v905.
     \vduring which an exception is raised\v1107.
     \vpriority\v911.
     \vprohibited for an abnormal task\v913.
\vReplacement of characters in program text\v212.
\vRepresentation (of a type and its objects)\v1301.
     \vrecommendation by a pragma\v1301.
\vRepresentation attribute\v1310.
     \vas a forcing occurrence\v1301.
     \vprefix which has a null value\v401.
\vRepresentation clause\v1301.
     \van an overload resolution context\v807.
     \vas a basic declarative item\v333.
     \vas a portion of a declarative region\v801.
     \vcannot include a forcing occurrence\v1301.
     \vfor a derived type\v309.
     \vfor a private type\v705.
     \vimplied for a derived type\v309.
     \vin an overload resolution context\v807.
     \vin a task specification\v901.
\vReserved word\v211.
\uRESET (input-output procedure)\n
     \vin an instance of direct_io\v1403.
     \vin an instance of sequential_io\v1403.
     \vin text_io\v1403.
\vResult subtype (of a function)\v601.
     \vof a return expression\v509.
\vResult type and overload resolution\v610.
\vReturn statement\v509.
     \vas a simple statement\v501.
     \vcausing a loop to be exited\v506.
     \vcausing a transfer of control\v501.
     \vcompleting block statement execution\v904.
     \vcompleting subprogram execution\v904.
     \vexpression which is an array aggregate\v409.
     \vin a function body\v609.
\uReturned value\n
     \vof a function call\v509.
     \vof an instance of a generic formal function\v1204.
     \vof a main program\v1001.
     \vof an operation\v308.
     \vof a predefined operator of an integer type\v314.
     \vof a predefined operator of a real type\v316.
\vRight label bracket compound delimiter\v202.
\uRight parenthesis\n
     \vcharacter\v201.
     \vdelimiter\v202.
\uRounding\n
     \vin a real-to-integer conversion\v419.
     \vof results of real operations\v418.
\vRun time check\v1109.
\u- S -\n
\vSafe interval\v418.
\vSafe number (of a real type)\v316.
     \vlimit to the result of a real operation\v418.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
     \vresult of universal expression too large\v423.
\vSAFE_EMAX (predefined attribute)\v318.
\vSAFE_LARGE (predefined attribute)\v318.
\vSAFE_SMALL (predefined attribute)\v318.
\vSatisfy (a constraint)\v305.
     \va discriminant constraint\v327.
     \van index constraint\v322.
     \va range constraint\v310.
\vScalar type\v305.
     \vas a generic parameter\v1203.
     \vformal parameter\v602.
     \vof a range in a membership test\v413.
     \voperation\v315.
\vScheduling\v911.
\vScope\v802.
     \vof a use clause\v804.
\vSecondary unit\v1001.
     \vcompiled after the corresponding library unit or parent unit\v1006.
     \vsubject to pragma elaborate\v1008.
\vSECONDS (predefined function)\v906.
\vSelect alternative (of a selective wait)\v908.
\vSelect statement\v907.
     \vas a compound statement\v501.
     \vin an abnormal task\v913.
\vSelected component\v404.
     \vas a basic operation\v308.
     \vas a name\v401.
     \vas the name of an entry or entry family\v905.
     \vfor selective visibility\v803.
     \vin a conforming construct\v604.
     \vstarting with standard\v806.
     \vusing a block name\v507.
     \vusing a loop name\v506.
     \vwhose prefix denotes a package\v803.
     \vwhose prefix denotes a record object\v803.
     \vwhose prefix denotes a task object\v803.
\vSelection of an exception handler\v1104.
\vSelective wait\v908.
     \vaccepting a conditional entry call\v909.
     \vaccepting a timed entry call\v910.
     \vraising program_error\v1101.
\vSelector\v404.
\vSemicolon character\v201.
\vSemicolon delimiter\v202.
     \vfollowed by a pragma\v210.
\vSEND_CONTROL (low_level_io procedure)\v1421.
\vSeparate compilation\v1000.
     \vof a proper body\v333.
     \vof a proper body declared in another compilation unit\v1004.
\vSeparator\v202.
\vSequence of statements\v501.
     \vin an accept statement\v905.
     \vin a basic loop\v506.
     \vin a block statement\v507.
     \vin a case statement alternative\v505.
     \vin a conditional entry call\v909.
     \vin an exception handler\v1102.
     \vin an if statement\v504.
     \vin a package body\v701.
     \vin a  selective wait statement\v908.
     \vin a subprogram body\v603.
     \vin a task body\v901.
     \vin a timed entry call\v910.
     \vincluding a raise statement\v1103.
     \vof code statements\v1312.
     \vraising an exception\v1105.
\vSequential access file\v1402.
\vSequential input-output\v1404.
\vSEQUENTIAL_IO (predefined input-output generic package)\v1402.
     \vexceptions\v1419.
     \vspecification\v1405.
\vSET_COL (text_io procedure)\v1412.
\vSET_INDEX (input-output procedure) in an instance of direct_io\v1406.
\vSET_INPUT (text_io procedure)\v1410.
     \vraising an exception\v1419.
\vSET_LINE (text_io procedure)\v1412.
\vSET_LINE_LENGTH (text_io procedure)\v1411.
     \vraising an exception\v1419.
\vSET_OUTPUT (text_io procedure)\v1410.
     \vraising an exception\v1419.
\vSET_PAGE_LENGTH (text_io procedure)\v1411.
     \vraising an exception\v1419.
\vSHARED (predefined pragma)\v914.
\vShared variable (of two tasks)\v914.
\vSharp character\v201.
     \vreplacement by colon character\v212.
\vShort circuit control form\v411.
     \vas a basic operation\v308.
     \vin an expression\v410.
\vSHORT_FLOAT (predefined type)\v317.
\vSHORT_INTEGER (predefined type)\v314.
\vSign of a fixed point number\v319.
\vSign of a floating point number\v317.
\vSignificant decimal digits\v317.
\vSimple expression\v410.
     \vas a choice\v328.
     \vas a choice in an aggregate\v407.
     \vas a range bound\v310.
     \vfor an entry index in an accept statement\v905.
     \vin an address clause\v1305.
     \vin a delay statement\v906.
     \vin a fixed accuracy definition\v319.
     \vin a floating accuracy definition\v317.
     \vin a record representation clause\v1304.
     \vin a relation\v410.
\vSimple name\v401.
     \vas a choice\v328.
     \vas a formal parameter\v606.
     \vas a label\v501.
     \vas a name\v401.
     \vbefore arrow compound delimiter\v803.
     \vin an accept statement\v905.
     \vin an address clause\v1305.
     \vin an attribute designator\v405.
     \vin a conforming construct\v604.
     \vin a discriminant association\v327.
     \vin an enumeration representation clause\v1303.
     \vin a package body\v701.
     \vin a selector\v404.
     \vin a suppress pragma\v1109.
     \vin a task body\v901.
     \vin a variant part\v328.
     \vin a with clause\v1002.
     \vversus identifier\v301.
\vSimple statement\v501.
\uSIZE (input-output function)\n
     \vin an instance of direct_io\v1406.
\vSIZE (predefined attribute)\v1310.
     \vspecified by a length clause\v1302.
\vSKIP_LINE (text_io procedure)\v1412.
     \vraising an exception\v1419.
\vSKIP_PAGE (text_io procedure)\v1412.
     \vraising an exception\v1419.
\vSlice\v403.
     \vas a basic operation\v308.
     \vas a name\v401.
     \vas destination of an assignment\v503.
     \vof a constant\v303.
     \vof a derived type\v309.
     \vof an object as an object\v302.
     \vof a value of a generic formal array type\v1203.
     \vof a variable\v303.
     \vstarting with a prefix\v401.
\vSMALL (predefined attribute)\v318.
     \vspecified by a length clause\v1302.
\vSmall of a fixed point number\v319.
\vSpace character\v201.
     \vas a separator\v202.
     \vin a comment\v209.
     \vnot allowed in an identifier\v203.
     \vnot allowed in a numeric literal\v205.
\vSpace character literal\v207.
\vSpecial character\v201.
     \vin a delimiter\v202.
\vSTANDARD (predefined package)\v806.
     \vas a declarative region\v801.
     \venclosing the library units of a program\v1002.
     \vincluding implicit declarations of fixed point\v416.
        \vcross-multiplication and cross-division\v416.
\vSTANDARD_INPUT (text_io function)\v1410.
\vSTANDARD_OUTPUT (text_io function)\v1410.
\uStar\n
     \vcharacter\v201.
     \vdelimiter\v202.
\vStatement\v501.
     \vallowed in an exception handler\v1102.
     \vas an overload resolution context\v807.
     \voptimized\v1009.
     \vraising an exception\v1105.
     \vthat cannot be reached\v1009.
\vStatic constraint\v422.
     \von a subcomponent subject to a component clause\v1304.
     \von a type\v314.
\vStatic discrete range\v422.
     \vas a choice of an aggregate\v409.
     \vas a choice of a case statement\v505.
     \vas a choice of a variant part\v328.
\vStatic expression\v422.
     \vas a bound in an integer type definition\v314.
     \vas a choice in a case statement\v505.
     \vas a choice of a variant part\v328.
     \vfor a choice in a record aggregate\v409.
     \vfor a discriminant in a record aggregate\v408.
     \vin an attribute designator\v405.
     \vin an enumeration representation clause\v1303.
     \vin a fixed accuracy definition\v319.
     \vin a floating accuracy definition\v317.
     \vin a generic unit\v1201.
     \vin a length clause\v1302.
     \vin a number declaration\v302.
     \vin a record representation clause\v1304.
     \vin priority pragma\v911.
     \vwhose type is a universal type\v423.
\vStatic others choice\v409.
\vStatic subtype\v422.
     \vof a discriminant\v328.
     \vof the expression in a case statement\v505.
\vSTATUS_ERROR (input-output exception)\v1419.
\vStorage address of a component\v1304.
\uStorage bits\n
     \vallocated to an object or type\v1302.
     \vof a record component relative to a storage unit\v1304.
     \vsize of a storage unit\v1308.
\vStorage reclamation\v421.
\vStorage representation of a record\v1304.
\vStorage unit\v1308.
     \voffset to the start of a record component\v1304.
     \vsize of a storage unit in bits\v1308.
\uStorage units allocated\n
     \vto a collection\v1302.
     \vto a task activation\v1302.
\vSTORAGE_ERROR (predefined exception)\v1101.
     \vraised by an allocator exceeding the allocated storage\v421.
     \vraised by an elaboration of a declarative item\v1101.
     \vraised by a task activation exceeding the allocated storage\v1101.
     \vraised by the execution of a subprogram call\v1101.
\vSTORAGE_SIZE (predefined attribute)\v1310.
     \vfor an access type\v332.
     \vfor a task object or task type\v912.
     \vspecified by a length clause\v1302.
\vSTORAGE_UNIT (predefined pragma)\v1308.
\vSTRING (predefined type)\v324.
     \vas the parameter of value attribute\v315.
     \vas the result of image attribute\v315.
\vString bracket\v208.
\vString literal\v208.
     \vas a basic operation\v308.
     \vas an operator symbol\v601.
     \vas a primary\v410.
     \vmay not be the argument of a conversion\v419.
     \vreplaced by a catenation of basic characters\v212.
\vSubaggregate\v409.
\vSubcomponent\v305.
     \vdepending on a discriminant\v326.
     \vof a component for which a component clause is given\v1304.
     \vrenamed\v805.
     \vthat is a task object\v902.
     \vwhose type is a limited type\v708.
     \vwhose type is a private type\v705.
\vSubprogram\v600.
     \vas a generic instance\v1206.
     \vas a main program\v1001.
     \vas an operation\v308.
     \vincluding a raise statement\v1103.
     \vof a derived type\v309.
     \voverloaded\v610.
     \vrenamed\v805.
     \vsubject to an address clause\v1305.
     \vsubject to an inline pragma\v605.
     \vsubject to an interface pragma\v1313.
     \vsubject to a representation clause\v1301.
     \vsubject to a suppress pragma\v1109.
     \vwith a separately compiled body\v1002.
\vSubprogram body\v603.
     \vas a generic body\v1205.
     \vas a library unit\v1001.
     \vas a proper body\v333.
     \vas a secondary unit\v1001.
     \vas a secondary unit compiled after the corresponding library unit\v1006.
     \vhaving dependent tasks\v904.
     \vin a package body\v701.
     \vincluding an exception handler\v1102.
     \vincluding an exit statement\v508.
     \vincluding a goto statement\v510.
     \vincluding an implicit declaration\v501.
     \vincluding a return statement\v508.
     \vincluding code statements must be a procedure body\v1312.
     \vinlined in place of each call\v605.
     \vmust be in the same declarative part as the declaration\v333.
     \vnot allowed for a subprogram subject to an interface pragma\v1313.
     \vnot yet elaborated at a call\v333.
     \vraising an exception\v1105.
     \vrecompiled\v1006.
\vSubprogram call\v606.
     \vbefore elaboration of the body\v333.
     \vstatement replaced by an inlining of the body\v605.
     \vstatement with a default actual parameter\v608.
     \vto a derived subprogram\v309.
     \vto a generic instance\v1200.
\vSubprogram declaration\v601.
     \vand body as a declarative region\v801.
     \vas a basic declaration\v301.
     \vas a later declarative item\v333.
     \vas a library unit\v1001.
     \vas an overloaded declaration\v803.
     \vimplied by the body\v603.
     \vin a package specification\v701.
     \vmade directly visible by a use clause\v804.
     \vof an operator\v611.
     \vrecompiled\v1006.
\vSubprogram specification\v601.
     \vand  forcing occurrence\v1301.
     \vconforming to another\v604.
     \vfor a function\v609.
     \vin a body stub\v1004.
     \vin a generic declaration\v1201.
     \vin a renaming declaration\v805.
     \vin a subprogram body\v603.
     \vincluding the name of a private type\v705.
     \vof a derived subprogram\v309.
\vSubtraction operation\v414.
     \vfor a real type\v418.
\vSubtype\v305.
     \vdeclared by a numeric type declaration\v314.
     \vin a membership test\v413.
     \vnot considered in overload resolution\v807.
     \vof an access type\v330.
     \vof an actual parameter\v607.
     \vof a component of an array\v321.
     \vof a component of a record\v325.
     \vof a constant in a static expression\v422.
     \vof a discriminant of a generic formal type\v1208.
     \vof a formal parameter\v607.
     \vof a formal parameter or result of a renamed subprogram or entry\v805.
     \vof a generic formal type\v1203.
     \vof an index of a generic formal array type\v1210.
     \vof a private type\v704.
     \vof a real type\v317.
     \vof a scalar type\v310.
     \vof a task type\v902.
     \vof a variable\v502.
     \vsubject to a representation clause\v1301.
\vSubtype conversion\v419.
     \vin an array assignment\v503.
     \vto a real type\v418.
\vSubtype declaration\v307.
     \vand forcing occurrences\v1301.
     \vas a basic declaration\v301.
     \vincluding the name of a private type\v705.
\vSubtype indication\v307.
     \vas a component subtype indication\v325.
     \vas a discrete range\v321.
     \vfor a subtype of a generic formal type\v1203.
     \vin an access type definition\v330.
     \vin an allocator\v421.
     \vin an array type definition\v321.
     \vin a component declaration\v325.
     \vin a constrained array definition\v321.
     \vin a derived type definition\v309.
     \vin a generic formal part\v1201.
     \vin an object declaration\v302.
     \vin an unconstrained array definition\v321.
     \vincluding a fixed point constraint\v319.
     \vincluding a floating point constraint\v317.
     \vwith a range constraint\v310.
\vSubunit\v1004.
     \vas a compilation unit\v1007.
     \vas a library unit\v1007.
     \vas a secondary unit\v1001.
     \vcompiled after the corresponding parent unit\v1006.
     \vnot allowed for a subprogram subject to an interface pragma\v1313.
     \vof a compilation unit subject to a context clause\v1002.
     \vraising an exception\v1105.
     \vrecompiled (does not affect other compilation units)\v1006.
\vSUCC (predefined attribute)\v315.
\vSUPPRESS (predefined pragma)\v1109.
\vSyntactic category\v107.
\vSyntax notation\v107.
\vSyntax rule\v107.
\vSYSTEM (predefined library package)\v1308.
\vSystem dependent\v2000.
     \vattribute\v1304.
     \vconstant\v1308.
     \vnamed number\v1308.
     \vrecord component\v1304.
     \vtype\v1308.
\vSYSTEM.ADDRESS (predefined type)\v1308.
\vSYSTEM.FINE_DELTA (predefined named number)\v1309.
\vSYSTEM.MAX_DIGITS (predefined named number)\v1309.
     \vlimit on the significant digits of a floating point type\v317.
\vSYSTEM.MAX_INT (predefined named number)\v1309.
     \vexceeded by the value of a universal expression\v423.
\vSYSTEM.MAX_MANTISSA (predefined named number)\v1309.
\vSYSTEM.MEMORY_SIZE (predefined named number)\v1308.
\vSYSTEM.MIN_INT (predefined named number)\v1309.
     \vgreater than the value of a universal expression\v423.
\vSYSTEM.NAME (predefined type)\v1308.
\vSYSTEM.STORAGE_UNIT (predefined named number)\v1308.
\vSYSTEM.SYSTEM_NAME (predefined constant)\v1308.
\vSYSTEM.TICK (predefined named number)\v1309.
\vSYSTEM_NAME (predefined pragma)\v1308.
\u- T -\n
\uTabulation\n
     \vhorizontal\v201.
     \vvertical\v201.
\vTarget statement (of a goto statement)\v510.
\vTarget type of a conversion\v419.
\vTask\v900.
     \vcalling the main program\v1001.
     \vraising an exception\v1107.
     \vscheduling\v911.
     \vsuspension awaiting a rendezvous\v905.
     \vsuspension by a selective wait\v908.
     \vsuspension of an abnormal task\v913.
\vTask activation\v903.
     \vbefore elaboration of the body\v333.
     \vcausing synchronization\v913.
     \vnot started for an abnormal task\v913.
     \vof a task with no task body\v1101.
\vTask body\v901.
     \vas a proper body\v333.
     \vin a package body\v701.
     \vincluding an exception handler\v1102.
     \vincluding an exit statement\v508.
     \vincluding a goto statement\v510.
     \vincluding an implicit declaration\v501.
     \vmust be in the same declarative part as the declaration\v333.
     \vnot yet elaborated at an activation\v333.
     \vraising an exception\v1105.
     \vspecifying the execution of a task\v902.
\vTask declaration\v901.
     \vand body as a declarative region\v801.
     \vas a basic declaration\v301.
     \vas a later declarative item\v333.
     \velaboration raising an exception\v1106.
     \vin a package specification\v701.
\uTask designated\n
     \vby a formal parameter\v602.
     \vby a value of a task type\v901.
\vTask execution\v903.
\vTask object\v902.
     \vdesignated by an access value\v902.
     \vdetermining task dependence\v904.
     \vrenamed\v805.
\vTask priority\v911.
     \vof a task with an interrupt entry\v1306.
\vTask specification\v901.
     \vincluding an entry declaration\v905.
     \vincluding a priority pragma\v911.
     \vincluding a representation clause\v1301.
\vTask synchronization\v905.
\vTask type\v901.
     \vcompleting an incomplete type definition\v331.
     \vformal parameter\v602.
     \vobject initialization\v303.
     \vvalue designating a task object\v303.
\vTask unit\v901.
     \vdeclaration determining the visibility of another declaration\v803.
     \vincluding a raise statement\v1103.
     \vsubject to an address clause\v1305.
     \vsubject to a representation clause\v1301.
     \vsubject to a suppress pragma\v1109.
     \vwith a separately compiled body\v1004.
\vTASKING_ERROR (predefined exception)\v1101.
     \vraised by an entry call to an abnormal task\v913.
     \vraised by an entry call to a completed task\v905.
     \vraised by an exception in the task body\v1106.
     \vraised by failure of an activation\v903.
\vTerm\v410.
     \vin a simple expression\v410.
\vTerminate alternative (of a selective wait)\v908.
     \vcausing a transfer of control\v501.
     \vin a select statement causing a loop to be exited\v506.
     \vselection\v904.
     \vselection in the presence of an accept alternative for\v1306.
        \van interrupt entry\v1306.
\vTERMINATED (predefined attribute) for a task object\v912.
\vTerminated task\v904.
     \vnot becoming abnormal\v913.
     \vobject designated by an access value\v421.
     \vtermination of a task during its activation\v903.
\vText input-output\v1408.
\vText of a program\v202.
\vTEXT_IO (predefined input-output package)\v1408.
     \vexceptions\v1419.
     \vspecification\v1418.
\vTIME (predefined type)\v906.
\vTIME_OF (predefined function)\v906.
\vTimed entry call\v910.
     \vand renamed entries\v805.
     \vsubject to an address clause\v1306.
\vTRUE boolean enumeration literal\v313.
\vType\v305.
     \vname\v306.
     \vof an actual parameter\v607.
     \vof an aggregate\v408.
     \vof an array component of a generic formal array type\v1210.
     \vof an array index of a generic formal array type\v1210.
     \vof a case statement expression\v505.
     \vof a condition\v504.
     \vof a declared object\v302.
     \vof a discriminant of a generic formal private type\v1208.
     \vof an expression\v410.
     \vof a file\v1401.
     \vof a formal parameter of a generic formal subprogram\v1204.
     \vof a generic actual object\v1207.
     \vof a generic formal object\v1202.
     \vof an index\v402.
     \vof a loop parameter\v506.
     \vof a named number\v302.
     \vof an object designated by a generic formal access types\v1211.
     \vof a primary in an expression\v410.
     \vof a shared variable\v914.
     \vof a slice\v403.
     \vof a task object\v902.
     \vof a universal expression\v423.
     \vof a value\v305.
     \vof discriminants of a generic formal object and the matching\v1208.
        \vactual object\v1208.
     \vof the literal null\v406.
     \vof the result of a generic formal function\v1204.
     \vrenamed\v805.
     \vsubject to a representation clause\v1301.
     \vsubject to a suppress pragma\v1109.
     \vyielded by an attribute\v405.
\vType conversion\v419.
     \vas an actual parameter\v606.
     \vas a primary\v410.
     \vin a static expression\v422.
     \vto a real type\v418.
\vType declaration\v306.
     \vas a basic declaration\v301.
     \vas a full declaration\v705.
     \vimplicitly declaring operations\v308.
     \vin a package specification\v701.
     \vincluding the name of a private type\v705.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
     \vof an integer type\v314.
     \vof a subtype\v1301.
\vType definition\v306.
\vType mark (denoting a type or subtype)\v307.
     \vas a generic actual parameter\v1206.
     \vin an allocator\v421.
     \vin a code statement\v1312.
     \vin a conversion\v419.
     \vin a deferred constant declaration\v704.
     \vin a discriminant specification\v326.
     \vin a generic formal part\v1201.
     \vin a generic parameter declaration\v1207.
     \vin an index subtype definition\v321.
     \vin a parameter specification\v601.
     \vin a qualified expression\v420.
     \vin a relation\v410.
     \vin a renaming declaration\v805.
     \vin a subprogram specification\v601.
     \vof a formal parameter of a generic formal subprogram\v1204.
     \vof a generic formal array type\v1203.
     \vof a static scalar subtype\v422.
     \vof the result of a generic formal function\v1204.
\vType with discriminants\v305.
     \vas an actual to a formal private type\v1208.
     \vas the component type of an array that is the operand\v419.
        \vof a conversion\v419.
\u- U -\n
\vUnary adding operator\v410.
     \vas an operation of a discrete type\v315.
     \vin a simple expression\v410.
     \voverloaded\v611.
\vUnary operator\v411.
        \vas an operation of a fixed point type\v311.
\vUNCHECKED_CONVERSION (predefined generic library function)\v1316.
\vUNCHECKED_DEALLOCATION (predefined generic library procedure)\v1315.
\vUnconstrained array definition\v321.
\vUnconstrained array type\v321.
     \vas an actual to a formal private type\v1208.
     \vformal parameter\v602.
     \vsubject to a length clause\v1302.
\vUnconstrained subtype\v305.
     \vindication in a generic unit\v1208.
\vUnconstrained type\v305.
     \vformal parameter\v602.
     \vwith discriminants\v607.
\vUnconstrained variable\v305.
\uUndefined value\n
     \vof a scalar parameter\v602.
     \vof a scalar variable\v303.
\vUnderline character\v201.
     \vin a based literal\v206.
     \vin a decimal literal\v205.
     \vin an identifier\v203.
\vUnhandled exception\v1105.
\vUniversal expression\v423.
     \vassigned\v502.
     \vin an attribute designator\v405.
     \vof a real type implicitly converted\v418.
     \vthat is static\v423.
\vUniversal type\v423.
     \vof a named number\v304.
\vUNIVERSAL_FIXED (predefined type)\v319.
     \vresult of fixed point multiplying operators\v416.
\vUNIVERSAL_INTEGER (predefined type)\v314.
     \vargument to a conversion\v308.
     \vattribute\v315.
     \vbounds of a discrete range\v322.
     \vbounds of a loop parameter\v506.
     \vcodes representing enumeration type values\v1303.
     \vconverted to an integer type\v315.
     \vof integer literals\v204.
     \vresult of an operation\v423.
\vUNIVERSAL_REAL (predefined type)\v316.
     \vargument to a conversion\v308.
     \vattribute\v1309.
     \vconverted to a fixed point type\v320.
     \vconverted to a floating point type\v318.
     \vof real literals\v204.
     \vresult of an operation\v423.
\vUpdating the value of an object\v602.
\vUpper case letter\v201.
     \vA to F in a based literal\v206.
     \vE in a decimal literal\v205.
     \vin an identifier\v203.
\vUse clause (to achieve direct visibility)\v804.
     \vas a basic declarative item\v333.
     \vas a later declarative item\v333.
     \vin a code procedure body\v1312.
     \vin a context clause of a compilation unit\v1002.
     \vin a context clause of a subunit\v1004.
     \vinserted by the environment\v1007.
\vUSE_ERROR (input-output exception)\v1419.
\u- V -\n
\vVAL (predefined attribute)\v315.
\uValue\n
     \vin a constant\v303.
     \vin a task object\v902.
     \vin a variable\v303.
     \vof an array type\v321.
     \vof a based literal\v206.
     \vof a boolean type\v313.
     \vof a character literal\v207.
     \vof a character type\v312.
     \vof a decimal literal\v205.
     \vof a fixed point type\v319.
     \vof a floating point type\v317.
     \vof a record type\v325.
     \vof a record type with discriminants\v326.
     \vof a string literal\v208.
     \vof a string type\v324.
\vVALUE (predefined attribute)\v315.
\vVariable\v303.
     \vas an actual parameter\v602.
     \vdeclared in a package body\v703.
     \vformal parameter\v602.
     \vin an assignment statement\v502.
     \vof an array type as destination of an assignment\v503.
     \vof a private type\v705.
     \vrenamed\v805.
     \vthat is a slice\v403.
\vVariable declaration\v303.
\vVariant\v328.
     \vin a variant part\v328.
\vVariant part\v328.
     \vin a component list\v325.
     \vin a record aggregate\v408.
\vVertical bar character\v201.
     \vreplacement by exclamation character\v212.
\vVertical bar delimiter\v202.
\vVertical tabulation format effector\v201.
\vVisibility\v803.
     \vand renaming\v805.
     \vdetermining multiple meanings of an identifier\v804.
     \vdetermining order of compilation\v1006.
     \vdue to a use clause\v804.
     \vof a basic operation\v803.
     \vof a character literal\v803.
     \vof a default for a generic formal subprogram\v1212.
     \vof a generic formal parameter\v1206.
     \vof a library unit due to a with clause\v806.
     \vof a name of an exception\v1102.
     \vof an operation declared in a package\v706.
     \vof an operator symbol\v803.
     \vof a renaming declaration\v805.
     \vof a subprogram declared in a package\v603.
     \vof declarations in a package body\v703.
     \vof declarations in a package specification\v702.
     \vof declarations in the package system\v1308.
     \vwithin a subunit\v1004.
\vVisibility by selection\v803.
\vVisible part (of a package)\v702.
     \vexpanded name denoting a declaration in a visible part\v802.
     \vuse clause naming the package\v804.
     \vvisibility of a declaration in a visible part\v803.
\u- W -\n
\uWait\n
  \vselective wait\v908.
\vWIDTH (predefined attribute)\v315.
\vWith clause\v1002.
     \vdetermining order of compilation\v1006.
     \vdetermining the implicit order of library units\v806.
     \vin a context clause of a compilation unit\v1002.
     \vin a context clause of a subunit\v1004.
     \vinserted by the environment\v1007.
     \vleading to direct visibility\v803.
\uWRITE (input-output procedure)\n
     \vin an instance of direct_io\v1406.
     \vin an instance of sequential_io\v1404.
\vWriting an output file\v1401.
\u- X -\n
\uXor operator\n
     \vlogical operator\v411.
\u- Y -\n
\vYEAR (predefined function)\v906.
1.       \uIntroduction\n
Ada  is  a  programming  language  designed in accordance with requirements
defined by the United States Department of Defense:  the so-called Steelman
requirements.   Overall,  these  requirements  call  for  a  language  with
considerable  expressive  power  covering  a wide application domain.  As a
result, the language includes facilities  offered  by  classical  languages
such  as  Pascal  as  well  as  facilities  often found only in specialized
languages.  Thus the language is a modern  algorithmic  language  with  the
usual  control  structures,  and  with  the  ability  to  define  types and
subprograms.  It also serves the need for modularity, whereby data,  types,
and  subprograms  can  be  packaged.   It treats modularity in the physical
sense as well, with a facility to support separate compilation.
In addition to these aspects, the language  covers  real-time  programming,
with  facilities to model parallel tasks and to handle exceptions.  It also
covers  systems  programming;   this  requires  precise  control  over  the
representation of data and access to system-dependent properties.  Finally,
both application-level and machine-level input-output are defined.
More details:
 1.1    \vScope of the Standard\v101.
 1.2    \vStructure of the Standard\v104.
 1.3    \vDesign Goals and Sources\v105.
 1.4    \vLanguage Summary\v106.
 1.5    \vSyntax Notation\v107.
 1.6    \vClassification of Errors\v108.
1.1      \uScope of the Standard\n
This  standard  specifies  the form and meaning of program units written in
Ada.  Its purpose is to promote  the  portability  of  Ada  programs  to  a
variety of data processing systems.
More details:
1.1.1  \vExtent of the Standard\v102.
1.1.2  \vConformity of an Implementation with the Standard\v103.
1.1.1    \uExtent of the Standard\n
This standard specifies:
(a)  The form of a program unit written in Ada.
(b)  The effect of translating and executing such a program unit.
(c)  The manner in  which  program  units  may  be  combined  to  form  Ada
     programs.
(d)  The predefined program units that  a  conforming  implementation  must
     supply.
(e)  The permissible variations within the  standard,  and  the  manner  in
     which they must be specified.
(f)  Those violations of the standard that a conforming  implementation  is
     required  to  detect,  and  the  effect  of attempting to translate or
     execute a program unit containing such violations.
(g)  Those violations of the standard that a conforming  implementation  is
     not required to detect.
This standard does not specify:
(h)  The means whereby a program unit written in Ada  is  transformed  into
     object code executable by a processor.
(i)  The means whereby translation or execution of program units is invoked
     and the executing units are controlled.
(j)  The size or speed of the object code, or the relative execution  speed
     of different language constructs.
(k)  The form or contents of any listings produced by implementations;   in
     particular, the form or contents of error or warning messages.
(l)  The effect of executing a program unit  that  contains  any  violation
     that a conforming implementation is not required to detect.
(m)  The size of a program or program unit that will exceed the capacity of
     a particular conforming implementation.
Where  this  standard  specifies  that a program unit written in Ada has an
exact effect, this effect is the operational meaning of  the  program  unit
and  must  be  produced  by  all  conforming  implementations.   Where this
standard specifies permissible variations in the effects of constituents of
a program unit written in Ada, the operational meaning of the program  unit
as  a  whole  is understood to be the range of possible effects that result
from all these variations, and a conforming implementation  is  allowed  to
produce  any of these possible effects.  Examples of permissible variations
  -  The represented values of fixed or floating  numeric  quantities,  and
     the results of operations upon them.
  -  The order of execution of statements in different parallel  tasks,  in
     the absence of explicit synchronization.
1.1.2    \uConformity of an Implementation With the Standard\n
A conforming implementation is one that:
(a)  Correctly translates and executes legal program units written in  Ada,
     provided  that  they are not so large as to exceed the capacity of the
     implementation.
(b)  Rejects all program units that are so large as to exceed the  capacity
     of the implementation.
(c)  Rejects all program units  that  contain  errors  whose  detection  is
     required by the standard.
(d)  Supplies all predefined program units required by the standard.
(e)  Contains no variations except where the standard permits.
(f)  Specifies all such permitted variations in the  manner  prescribed  by
     the standard.
1.2      \uStructure of the Standard\n
This  reference  manual  contains  fourteen  chapters, three annexes, three
appendices, and an index.
Each chapter is divided into sections that have a common  structure.   Each
section  introduces  its  subject,  gives  any  necessary syntax rules, and
describes the semantics of the corresponding language constructs.  Examples
and notes, and then references, may appear at the end of a section.
Examples are meant to illustrate  the  possible  forms  of  the  constructs
described.   Notes  are  meant  to  emphasize  consequences  of  the  rules
described in the section or elsewhere.  References are meant to attract the
attention of readers to a term or phrase having a technical meaning defined
in another section.
The standard definition of the Ada programming  language  consists  of  the
fourteen   chapters  and  the  three  annexes,  subject  to  the  following
restriction:   the  material  in  each  of  the  items  listed   below   is
informative, and not part of the standard definition of the Ada programming
language:
  -  Section 1.3 \vDesign goals and sources\v105.
  -  Section 1.4 \vLanguage summary\v106.
  -  The examples, notes, and references given at the end of each section
  -  Each section whose title starts with the word "Example" or  "Examples"
1.3      \uDesign Goals and Sources\n
Ada  was  designed with three overriding concerns:  program reliability and
maintenance, programming as a human activity, and efficiency.
The need for languages that promote reliability and simplify maintenance is
well established.  Hence emphasis was placed on  program  readability  over
ease  of  writing.   For  example,  the  rules of the language require that
program variables be explicitly declared and that their type be  specified.
Since  the  type  of  a  variable  is  invariant, compilers can ensure that
operations on variables are compatible with  the  properties  intended  for
objects of the type.  Furthermore, error-prone notations have been avoided,
and  the syntax of the language avoids the use of encoded forms in favor of
more English-like constructs.  Finally, the  language  offers  support  for
separate  compilation  of  program  units in a way that facilitates program
development and maintenance, and which provides the same degree of checking
between units as within a unit.
Concern for the human programmer  was  also  stressed  during  the  design.
Above  all,  an attempt was made to keep the language as small as possible,
given the ambitious nature of the application domain.  We have attempted to
cover this domain with a small number of underlying concepts integrated  in
a  consistent  and systematic way.  Nevertheless we have tried to avoid the
pitfalls of excessive involution, and in the constant  search  for  simpler
designs  we  have  tried  to  provide  language  constructs that correspond
intuitively to what the users will normally expect.
Like many other human activities, the development of programs  is  becoming
ever  more  decentralized  and  distributed.   Consequently, the ability to
assemble a program from independently produced software components has been
a central idea in this design.  The concepts of packages, of private types,
and of  generic  units  are  directly  related  to  this  idea,  which  has
ramifications in many other aspects of the language.
No  language  can  avoid the problem of efficiency.  Languages that require
over-elaborate compilers, or that lead to the inefficient use of storage or
execution time, force these inefficiencies  on  all  machines  and  on  all
programs.   Every  construct  of  the language was examined in the light of
present  implementation   techniques.    Any   proposed   construct   whose
implementation was unclear or that required excessive machine resources was
rejected.
None of the above design goals was considered as achievable after the fact.
The design goals drove the entire design process from the beginning.
A  perpetual  difficulty  in language design is that one must both identify
the capabilities required by the application  domain  and  design  language
features  that  provide these capabilities.  The difficulty existed in this
design, although to a lesser degree than  usual  because  of  the  Steelman
requirements.   These  requirements  often simplified the design process by
allowing it to concentrate on the design of a given system providing a well
defined  set  of  capabilities,  rather  than  on  the  definition  of  the
capabilities themselves.
Another significant simplification of the design work resulted from earlier
experience acquired by several successful Pascal derivatives developed with
similar goals.  These are the languages Euclid, Lis, Mesa, Modula, and Sue.
Many of the key ideas and syntactic forms developed in these languages have
counterparts  in  Ada.   Several  existing  languages  such as Algol 68 and
Simula, and also  recent  research  languages  such  as  Alphard  and  Clu,
influenced  this  language in several respects, although to a lesser degree
than did the Pascal family.
Finally, the evaluation reports received on  an  earlier  formulation  (the
Green  language),  and  on alternative proposals (the Red, Blue, and Yellow
languages), the language reviews that took place  at  different  stages  of
this project, and the thousands of comments received from fifteen different
countries  during  the  preliminary stages of the Ada design and during the
ANSI canvass, all had a significant impact on the  standard  definition  of
the language.
1.4      \uLanguage Summary\n
An  Ada  program  is  composed of one or more program units.  These program
units can be compiled separately.  Program units may be subprograms  (which
define  executable  algorithms), package units (which define collections of
entities), task units (which  define  parallel  computations),  or  generic
units  (which  define  parameterized  forms  of  packages and subprograms).
Each unit normally consists of two parts:  a specification, containing  the
information that must be visible to other units, and a body, containing the
implementation details, which need not be visible to other units.
This  distinction of the specification and body, and the ability to compile
units separately, allows a program to be designed, written, and tested as a
set of largely independent software components.
An Ada program will normally make use of a  library  of  program  units  of
general   utility.    The   language   provides  means  whereby  individual
organizations can construct their own libraries.  The text of a  separately
compiled program unit must name the library units it requires.
\uProgram Units\n
A  subprogram is the basic unit for expressing an algorithm.  There are two
kinds of subprograms:  procedures and functions.  A procedure is the  means
of  invoking  a  series  of actions.  For example, it may read data, update
variables, or produce some output.  It may have parameters,  to  provide  a
controlled means of passing information between the procedure and the point
of call.
A  function  is  the  means  of invoking the computation of a value.  It is
similar to a procedure, but in addition will return a result.
A package is the basic unit for defining a collection of logically  related
entities.   For  example,  a package can be used to define a common pool of
data and types, a collection of related  subprograms,  or  a  set  of  type
declarations  and  associated  operations.   Portions  of  a package can be
hidden from the user, thus allowing access only to the  logical  properties
expressed by the package specification.
A task unit is the basic unit for defining a task whose sequence of actions
may  be  executed in parallel with those of other tasks.  Such tasks may be
implemented  on  multicomputers,  multiprocessors,  or   with   interleaved
execution  on  a  single processor.  A task unit may define either a single
executing task or a task type permitting the  creation  of  any  number  of
similar tasks.
\uDeclarations and Statements\n
The  body  of  a  program unit generally contains two parts:  a declarative
part, which defines the logical entities to be used in  the  program  unit,
and  a  sequence  of statements, which defines the execution of the program
unit.
The declarative part associates names with declared entities.  For example,
a name may denote a type, a constant,  a  variable,  or  an  exception.   A
declarative  part  also introduces the names and parameters of other nested
subprograms, packages, task units, and generic units  to  be  used  in  the
program unit.
The  sequence  of statements describes a sequence of actions that are to be
performed.  The statements are executed  in  succession  (unless  an  exit,
return, or goto statement, or the raising of an exception, causes execution
to continue from another place).
An  assignment statement changes the value of a variable.  A procedure call
invokes execution of a procedure after associating  any  actual  parameters
provided at the call with the corresponding formal parameters.
Case  statements  and  if  statements  allow  the  selection of an enclosed
sequence of statements based on the value of an expression or on the  value
of a condition.
The  loop statement provides the basic iterative mechanism in the language.
A loop statement specifies that a sequence of statements is to be  executed
repeatedly  as  directed by an iteration scheme, or until an exit statement
is encountered.
A block statement comprises  a  sequence  of  statements  preceded  by  the
declaration of local entities used by the statements.
Certain  statements are only applicable to tasks.  A delay statement delays
the execution of a task for a specified duration.  An entry call  statement
is  written  as  a  procedure  call  statement;  it specifies that the task
issuing the call is ready for a rendezvous with another task that has  this
entry.   The  called  task  is  ready  to  accept  the  entry call when its
execution reaches a corresponding accept  statement,  which  specifies  the
actions then to be performed.  After completion of the rendezvous, both the
calling  task and the task having the entry may continue their execution in
parallel.  One form of the select statement allows a selective wait for one
of several alternative rendezvous.  Other forms  of  the  select  statement
allow conditional or timed entry calls.
Execution  of a program unit may encounter error situations in which normal
program execution cannot continue.  For example, an arithmetic  computation
may exceed the maximum allowed value of a number, or an attempt may be made
to  access  an  array component by using an incorrect index value.  To deal
with such error situations,  the  statements  of  a  program  unit  can  be
textually  followed  by  exception  handlers that specify the actions to be
taken when the error situation arises.  Exceptions can be raised explicitly
by a raise statement.
\uData Types\n
Every object in the language has a  type,  which  characterizes  a  set  of
values  and  a set of applicable operations.  The main classes of types are
scalar types (comprising enumeration and numeric types),  composite  types,
access types, and private types.
An  enumeration  type  defines  an  ordered  set  of  distinct  enumeration
literals, for example a list of states or an alphabet of  characters.   The
enumeration types BOOLEAN and CHARACTER are predefined.
Numeric  types provide a means of performing exact or approximate numerical
computations.  Exact computations use integer types, which denote  sets  of
consecutive  integers.   Approximate  computations  use  either fixed point
types, with absolute bounds on the error, or  floating  point  types,  with
relative  bounds  on  the  error.   The  numeric  types INTEGER, FLOAT, and
DURATION are predefined.
Composite types  allow  definitions  of  structured  objects  with  related
components.   The  composite  types  in the language provide for arrays and
records.  An array is an object with indexed components of the  same  type.
A  record  is  an object with named components of possibly different types.
The array type STRING is predefined.
A record may have special  components  called  discriminants.   Alternative
record structures that depend on the values of discriminants can be defined
within a record type.
Access  types  allow  the construction of linked data structures created by
the evaluation of allocators.  They allow several variables  of  an  access
type  to  designate  the  same  object,  and  components  of  one object to
designate the same or other objects.  Both the elements in  such  a  linked
data  structure  and their relation to other elements can be altered during
program execution.
Private types can be defined in a package that conceals structural  details
that  are  externally  irrelevant.  Only the logically necessary properties
(including any discriminants) are made visible to the users of such  types.
The  concept  of  a  type is refined by the concept of a subtype, whereby a
user can constrain the set of allowed values of a type.   Subtypes  can  be
used  to  define  subranges  of  scalar types, arrays with a limited set of
index values, and records and private types  with  particular  discriminant
values.
\uOther Facilities\n
Representation clauses can be used to specify the mapping between types and
features  of an underlying machine.  For example, the user can specify that
objects of a given type must be represented with a given number of bits, or
that the components of a record are to be represented using a given storage
layout.  Other features allow the controlled use of low level, nonportable,
or implementation-dependent aspects,  including  the  direct  insertion  of
machine code.
Input-output  is  defined  in  the  language by means of predefined library
packages.   Facilities  are  provided  for  input-output   of   values   of
user-defined   as   well   as  of  predefined  types.   Standard  means  of
representing values in display form are also provided.
Finally, the language provides a  powerful  means  of  parameterization  of
program units, called generic program units.  The generic parameters can be
types  and subprograms (as well as objects) and so allow general algorithms
to be applied to all types of a given class.
1.5      \uMethod of Description and Syntax Notation\n
The form of Ada program units is  described  by  means  of  a  context-free
syntax  together with context-dependent requirements expressed by narrative
rules.
The meaning of Ada program units is described by means of  narrative  rules
defining  both  the effects of each construct and the composition rules for
constructs.   This  narrative  employs  technical   terms   whose   precise
definition  is  given in the text (references to the section containing the
definition of a technical term appear at the end of each section that  uses
the term).
All other terms are in the English language and bear their natural meaning,
as  defined  in Webster's Third New International Dictionary of the English
Language.
The context-free syntax of the language is described using a simple variant
of Backus-Naur-Form.  In particular,
(a)  Lower case words, some containing embedded  underlines,  are  used  to
     denote syntactic categories, for example:
          adding_operator
     Whenever the name of a syntactic  category  is  used  apart  from  the
     syntax  rules  themselves,  spaces  take  the  place of the underlines
     (thus:  adding operator).
(b)  Boldface words are used to denote reserved words, for example:
          \uarray\n
(c)  Square brackets enclose optional items.  Thus the two following  rules
     are equivalent.
          return_statement ::= \ureturn\n [expression];
          return_statement ::= \ureturn\n; | \ureturn\n expression;
(d)  Braces enclose a repeated item.  The item  may  appear  zero  or  more
     times;  the repetitions occur from left to right as with an equivalent
     left-recursive rule.  Thus the two following rules are equivalent.
          term ::= factor {multiplying_operator factor}
          term ::= factor | term multiplying_operator factor
(e)  A  vertical  bar  separates  alternative  items   unless   it   occurs
     immediately  after  an  opening  brace,  in  which  case it stands for
     itself:
          letter_or_digit ::= letter | digit
          component_association ::= [choice {| choice} =>] expression
(f)  If the name of any syntactic category starts with an italicized  part,
     it  is  equivalent  to  the category name without the italicized part.
     The italicized part is intended to convey some  semantic  information.
     For example type_name and task_name are both equivalent to name alone.
Note:
The  syntax  rules describing structured constructs are presented in a form
that corresponds to the  recommended  paragraphing.   For  example,  an  if
statement is defined as
    if_statement ::=
        \uif\n condition \uthen\n
          sequence_of_statements
       {\uelsif\n condition \uthen\n
          sequence_of_statements}
       [\uelse\n
          sequence_of_statements]
        \uend if\n;
Different  lines  are  used for parts of a syntax rule if the corresponding
parts of the construct  described  by  the  rule  are  intended  to  be  on
different   lines.   Indentation  in  the  rule  is  a  recommendation  for
indentation of the corresponding part of the construct.  It is  recommended
that  all  indentations be by multiples of a basic step of indentation (the
number of spaces for the basic step is not defined).  The preferred  places
for  other  line  breaks  are  after  semicolons.   On the other hand, if a
complete construct can fit on  one  line,  this  is  also  allowed  in  the
recommended paragraphing.
1.6      \uClassification of Errors\n
The   language   definition   classifies   errors  into  several  different
categories:
(a)  Errors that  must  be  detected  at  compilation  time  by  every  Ada
     compiler.
     These  errors  correspond  to  any  violation  of a rule given in this
     reference manual, other than the violations that correspond to (b)  or
     (c)  below.   In particular, violation of any rule that uses the terms
     must, allowed, legal,  or  illegal  belongs  to  this  category.   Any
     program  that  contains  such an error is not a legal Ada program;  on
     the other hand, the fact that a program is legal does  not  mean,  per
     se, that the program is free from other forms of error.
(b)  Errors that must be detected at run time by the execution  of  an  Ada
     program.
     The  corresponding  error  situations are associated with the names of
     the predefined exceptions.  Every Ada compiler is required to generate
     code  that  raises  the  corresponding  exception  if  such  an  error
     situation arises during program execution.  If an exception is certain
     to  be  raised  in  every  execution  of a program, then compilers are
     allowed (although not required) to report  this  fact  at  compilation
     time.
(c)  Erroneous execution.
     The language rules specify certain rules to be obeyed by Ada programs,
     although  there is no requirement on Ada compilers to provide either a
     compilation-time or a run-time detection  of  the  violation  of  such
     rules.   The  errors  of this category are indicated by the use of the
     word  erroneous  to  qualify  the  execution  of   the   corresponding
     constructs.  The effect of erroneous execution is unpredictable.
(d)  Incorrect order dependences.
     Whenever  the  reference  manual  specifies  that different parts of a
     given construct are to be executed in some order that is  not  defined
     by  the  language,  this  means  that the implementation is allowed to
     execute these parts in any  given  order,  following  the  rules  that
     result  from  that given order, but not in parallel.  Furthermore, the
     construct is incorrect if execution of  these  parts  in  a  different
     order  would  have  a different effect.  Compilers are not required to
     provide either compilation-time or  run-time  detection  of  incorrect
     order dependences.  The foregoing is expressed in terms of the process
     that  is  called  execution;  it applies equally to the processes that
     are called evaluation and elaboration.
If a compiler is able to recognize at compilation time that a construct  is
erroneous  or  contains an incorrect order dependence, then the compiler is
allowed to generate, in place of  the  code  otherwise  generated  for  the
construct,   code  that  raises  the  predefined  exception  PROGRAM_ERROR.
Similarly, compilers are allowed to generate code that checks at  run  time
for  erroneous  constructs,  for  incorrect order dependences, or for both.
The predefined exception PROGRAM_ERROR is raised if such a check fails.
2.       \uLexical Elements\n
The  text  of  a program consists of the texts of one or more compilations.
The text of a \vcompilation\v1001. is a sequence of \vlexical elements\v202., each  composed
of  \vcharacters\v201.;   the  rules  of  composition  are  given  in this chapter.
\vPragmas\v210., which provide certain  information  for  the  compiler,  are  also
described in this chapter.
More details:
 2.1    \vCharacter Set\v201.
 2.2    \vLexical Elements, Separators and Delimiters\v202.
 2.3    \vIdentifiers\v203.
 2.4    \vNumeric Literals\v204.
 2.5    \vCharacter Literals\v207.
 2.6    \vString Literals\v208.
 2.7    \vComments\v209.
 2.8    \vPragmas\v210.
 2.9    \vReserved Words\v211.
 2.10   \vAllowed Replacements of Characters\v212.
2.1      \uCharacter Set\n
The only  characters allowed in the text  of  a  program  are  the  graphic
characters  and  format effectors.  Each graphic character corresponds to a
unique code of the ISO seven-bit coded character set  (ISO  standard  646),
and  is  represented  (visually)  by  a  graphical  symbol.   Some  graphic
characters are represented by different graphical  symbols  in  alternative
national  representations of the ISO character set.  The description of the
language definition in  this  standard  reference  manual  uses  the  ASCII
graphical  symbols,  the ANSI graphical representation of the ISO character
    graphic_character ::= basic_graphic_character
       | lower_case_letter | other_special_character
    basic_graphic_character ::=
         upper_case_letter | digit
       | special_character | space_character
    basic_character ::=
         basic_graphic_character | format_effector
The basic character  set  is  sufficient  for  writing  any  program.   The
characters  included  in each of the categories of basic graphic characters
are defined as follows:
(a)  upper case letters
     A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
(b)  digits
     0 1 2 3 4 5 6 7 8 9
(c)  special characters
     " # & ' ( ) * + , - . / : ; < = > _ |
(d)  the space character
Format effectors are the  ISO  (and  ASCII)  characters  called  horizontal
tabulation, vertical tabulation, carriage return, line feed, and form feed.
The  characters  included  in  each  of the remaining categories of graphic
characters are defined as follows:
(e)  lower case letters
     a b c d e f g h i j k l m n o p q r s t u v w x y z
(f)  other special characters
     ! $ % ? @ [ \\ ] ^ ` { } ~
Allowable replacements for the special characters vertical bar  (|),  sharp
(#), and quotation (") are defined in section 2.10.
\uNotes:\n
The  ISO  character  that  corresponds to the sharp graphical symbol in the
ASCII representation appears as a pound  sterling  symbol  in  the  French,
German, and United Kingdom standard national representations.  In any case,
the  font  design  of  graphical  symbols (for example, whether they are in
italic or bold typeface) is not part of the ISO standard.
The meanings of the acronyms used in this section  are  as  follows:   ANSI
stands for American National Standards Institute, ASCII stands for American
Standard Code for Information Interchange, and ISO stands for International
Organization for Standardization.
The following names are used when referring to special characters and other
special characters:
    symbol     name                        symbol     name
      "        quotation                     >        greater than
      #        sharp                         _        underline
      &        ampersand                     |        vertical bar
      '        apostrophe                    !        exclamation mark
      (        left parenthesis              $        dollar
      )        right parenthesis             %        percent
      *        star, multiply                ?        question mark
      +        plus                          @        commercial at
      ,        comma                         [        left square bracket
      -        hyphen, minus                 \\        back-slash
      .        dot, point, period            ]        right square bracket
      /        slash, divide                 ^        circumflex
      :        colon                         `        grave accent
      ;        semicolon                     {        left brace
      <        less than                     }        right brace
      =        equal                         ~        tilde
2.2      \uLexical Elements, Separators, and Delimiters\n
The  text  of  a program consists of the texts of one or more compilations.
The text of each \vcompilation\v1001. is a sequence of  separate  lexical  elements.
Each  lexical  element is either a delimiter, an \videntifier\v203. (which may be a
\vreserved word\v211.), a \vnumeric literal\v204., a \vcharacter literal\v207., a  \vstring  literal\v208.,
or  a  \vcomment\v209..   The  effect  of  a program depends only on the particular
sequences of lexical elements that form  its  compilations,  excluding  the
comments, if any.
In  some  cases  an  explicit  separator  is  required to separate adjacent
lexical elements (namely, when  without  separation,  interpretation  as  a
single  lexical  element  is  possible).   A  separator  is  any of a space
character, a \vformat effector\v201., or the end of a line.  A \vspace character\v201. is a
separator except within a comment, a string literal, or a  space  character
literal.   Format  effectors  other  than  horizontal tabulation are always
separators.  Horizontal tabulation is a separator except within a  comment.
The end of a line is always a separator.  The language does not define what
causes  the end of a line.  However if, for a given implementation, the end
of a line is signified by one or more  characters,  then  these  characters
must  be format effectors other than horizontal tabulation.  In any case, a
sequence of one or more format effectors other than  horizontal  tabulation
must cause at least one end of line.
One  or  more  separators  are  allowed  between  any  two adjacent lexical
elements, before the first of each compilation,  or  after  the  last.   At
least  one separator is required between an identifier or a numeric literal
and an adjacent identifier or numeric literal.
A delimiter is either one of the following \vspecial characters\v201. (in the basic
character set)
    & ' ( ) * + , - . / : ; < = > |
or one of the following compound delimiters each composed of  two  adjacent
special characters
    =>   ..   **   :=   /=   >=   <=   <<   >>   <>
Each  of the special characters listed for single character delimiters is a
single delimiter except if this character is  used  as  a  character  of  a
compound  delimiter,  or  as  a  character  of  a  comment, string literal,
character literal, or numeric literal.
The remaining forms of lexical element are described in other  sections  of
this chapter.
\uNotes:\n
Each  lexical  element  must  fit on one line, since the end of a line is a
separator.  The quotation, sharp, and underline  characters,  likewise  two
adjacent  hyphens,  are  not delimiters, but may form part of other lexical
elements.
The following names are used when referring to compound delimiters:
    delimiter     name
       =>         arrow
       ..         double dot
       **         double star, exponentiate
       :=         assignment (pronounced: "becomes")
       /=         inequality (pronounced: "not equal")
       >=         greater than or equal
       <=         less than or equal
       <<         left label bracket
       >>         right label bracket
       <>         box
2.3      \uIdentifiers\n
Identifiers are used as \vnames\v401. and also as \vreserved words\v211..
    identifier ::=
       letter {[underline] letter_or_digit}
    letter_or_digit ::= letter | digit
    letter ::= upper_case_letter | lower_case_letter
All  characters  of  an identifier are significant, including any underline
character inserted between a letter or \vdigit\v201.  and  an  adjacent  letter  or
digit.   Identifiers  differing  only in the use of corresponding upper and
\vlower case letters\v201. are considered as the same.
\uExamples:\n
    COUNT      X    get_symbol   Ethelyn   Marion
    SNOBOL_4   X1   PageCount    STORE_NEXT_ITEM
Note:
No space is allowed within an identifier since a \vspace\v201. is a \vseparator\v202..
2.4      \uNumeric Literals\n
There are two classes of  numeric  \vliterals\v406.:   real  literals  and  integer
literals.   A  real literal is a numeric literal that includes a point;  an
integer literal is a numeric literal without a point.   Real  literals  are
the literals of the type \vuniversal_real\v316..  Integer literals are the literals
of the type \vuniversal_integer\v314..
    numeric_literal ::= decimal_literal | based_literal
More details:
 2.4.1  \vDecimal Literals\v205.
 2.4.2  \vBased Literals\v206.
2.4.1    \uDecimal Literals\n
A  decimal  literal  is  a  numeric  literal  expressed in the conventional
decimal notation (that is, the base is implicitly ten).
    decimal_literal ::= integer [.integer] [exponent]
    integer  ::= digit {[underline] digit}
    exponent ::= E [+] integer | E - integer
An underline character  inserted  between  adjacent  \vdigits\v201.  of  a  decimal
literal does not affect the value of this \vnumeric literal\v204..  The letter E of
the exponent, if any, can be written either in \vlower case\v201. or in upper case,
with the same meaning.
An  exponent  indicates  the power of ten by which the value of the decimal
literal without the exponent is to be multiplied to obtain the value of the
decimal literal with the exponent.  An exponent for an integer literal must
not have a minus sign.
\uExamples:\n
    12        0      1E6    123_456     --  integer literals
    12.0      0.0    0.456  3.14159_26  --  real literals
    1.34E-12  1.0E+6  --  real literals with exponent
\uNotes:\n
Leading zeros are allowed.  No space is allowed in a numeric  literal,  not
even between constituents of the exponent, since a \vspace\v201. is a \vseparator\v202..  A
zero exponent is allowed for an integer literal.
2.4.2    \uBased Literals\n
A based literal is a \vnumeric literal\v204. expressed in a form that specifies the
base explicitly.  The base must be at least two and at most sixteen.
    based_literal ::=
       base # based_integer [.based_integer] # [exponent]
    base ::= integer
    based_integer ::=
       extended_digit {[underline] extended_digit}
    extended_digit ::= digit | letter
An underline character inserted between adjacent \vdigits\v201. of a based  literal
does  not  affect  the  value  of  this  numeric literal.  The base and the
\vexponent\v205., if any, are in decimal notation.  The  only  \vletters\v203.  allowed  as
extended  digits  are  the  letters  A through F for the digits ten through
fifteen.  A letter in a based literal (either  an  extended  digit  or  the
letter  E  of  an exponent) can be written either in \vlower\v201. case or in \vupper\v201.
case, with the same meaning.
The conventional meaning of based notation is assumed;  in  particular  the
value of each extended digit of a based literal must be less than the base.
An exponent indicates the power of the base by which the value of the based
literal without the exponent is to be multiplied to obtain the value of the
based literal with the exponent.
\uExamples:\n
  2#1111_1111#   16#FF#       016#0FF#    --  integer literals of value 255
  16#E#E1        2#1110_0000 #            --  integer literals of value 224
  16#F.FF#E+2    2#1.1111_1111_111#E11    --  real literals of value 4095.0
2.5      \uCharacter Literals\n
A character  \vliteral\v406.   is  formed  by  enclosing  one  of  the  95  \vgraphic\v201.
characters  (including  the  \vspace\v201.)  between  two apostrophe characters.  A
character  has a value that belongs to a \vcharacter type\v312..
    character_literal ::= 'graphic_character'
\uExamples:\n
    'A'   '*'   '''   ' '
2.6      \uString Literals\n
A  string  literal  is formed by a sequence of \vgraphic characters\v201. (possibly
none) enclosed between two quotation characters used as string brackets.
    string_literal ::= "{graphic_character}"
A string literal has a  value  that  is  a  sequence  of  \vcharacter  values\v312.
corresponding  to  the  graphic characters of the string literal apart from
the quotation character itself.  If a quotation character value  is  to  be
represented  in  the  sequence of character values, then a pair of adjacent
quotation characters must be written at the corresponding place within  the
string  literal.   (This  means  that  a  string  literal that includes two
adjacent quotation characters is never interpreted as two  adjacent  string
literals.)
The  length  of  a  string literal is the number of character values in the
sequence represented.  (Each doubled quotation character is  counted  as  a
single character.)
\uExamples:\n
    "Message of the day:"
    ""                     --  an empty string literal
    " "   "A"   """"       --  three string literals of length 1
    "Characters such as $, %, and } are allowed in string literals"
Note:
A  string  literal  must fit on one line since it is a \vlexical element\v202. (see
2.2).  Longer sequences of graphic character  values  can  be  obtained  by
\vcatenation\v414.  of string literals.  Similarly catenation of \vconstants\v303. \vdeclared\v301.
in the package ASCII can be used to obtain sequences  of  character  values
that   include   nongraphic   character   values   (the  so-called  control
characters).  Examples of such uses of catenation are given below:
    "FIRST PART OF A SEQUENCE OF CHARACTERS " &
    "THAT CONTINUES ON THE NEXT LINE"
    "sequence that includes the" & ASCII.ACK & "control character"
2.7      \uComments\n
A comment starts with two adjacent hyphens and extends up to the \vend of the\v202.
\vline\v202..  A comment can appear on any line of  a  program.   The  presence  or
absence  of  comments  has  no  influence  on whether a program is \vlegal\v108. or
\villegal\v108..  Furthermore,  comments do not influence the effect of a  program;
their sole purpose is the enlightenment of the human reader.
\uExamples:\n
    --  the last sentence above echoes the Algol 68 report
    \uend\n;  --  processing of LINE is complete
    --  a long comment may be split onto
    --  two or more consecutive lines
    ----------------  the first two hyphens start the comment
Note:
Horizontal  tabulation  can   be used in comments, after the double hyphen,
and is equivalent to one or more \vspaces\v201. (see 2.2).
2.8      \uPragmas\n
A pragma is used to convey information to the \vcompiler\v1001..   A  pragma  starts
with the \vreserved word\v211. pragma followed by an identifier that is the name of
the pragma.
    \upragma\n ::=
       \upragma\n \videntifier\v203. [(argument_association {, argument_association})];
    argument_association ::=
         [argument_identifier =>] \vname\v401.
       | [argument_identifier =>] \vexpression\v410.
Pragmas are only allowed at the following places in a program:
  -  After  a  semicolon  \vdelimiter\v202.,  but  not  within  a  \vformal  part\v601.  or
     \vdiscriminant part\v326..
  -  At any place where the syntax rules allow a  construct  defined  by  a
     syntactic  category  whose  name ends with "declaration", "\vstatement\v500.",
     "clause", or "alternative", or one of the syntactic categories \vvariant\v328.
     and \vexception handler\v1102.;  but not in place of such a construct.  Also at
     any place where a compilation unit would be allowed.
Additional restrictions exist for the placement of specific pragmas.
Some  pragmas  have  arguments.   Argument  associations  can   be   either
positional  or named as for parameter associations of subprogram calls (see
6.4).  Named associations are,  however,  only  possible  if  the  argument
identifiers are defined.  A name given in an argument must be either a name
\vvisible\v803. at the place of the pragma or an identifier specific to the pragma.
The pragmas defined by the language are described in Annex B:  they must be
supported  by  every  implementation.   In  addition, an implementation may
provide \vimplementation-defined pragmas\v2000., which must  then  be  described  in
Appendix  F.   An  implementation  is  not  allowed to define pragmas whose
presence or absence influences  the  \vlegality\v108.  of  the  text  outside  such
pragmas.   Consequently,  the  legality of a program does not depend on the
presence or absence of implementation-defined pragmas.
A pragma that is not \vlanguage-defined\v1600. has no effect if  its  identifier  is
not  recognized  by  the  (current)  implementation.  Furthermore, a pragma
(whether language-defined or implementation-defined) has no effect  if  its
placement  or  its  arguments  do not correspond to what is allowed for the
pragma.  The region of text over which a pragma has an  effect  depends  on
the pragma.
\uExamples:\n
    \upragma\n LIST(OFF);
    \upragma\n OPTIMIZE(TIME);
    \upragma\n INLINE(SETMASK);
    \upragma\n SUPPRESS(RANGE_CHECK, ON => INDEX);
Note:
It  is  recommended  (but not required) that implementations issue warnings
for pragmas that are not recognized and therefore ignored.
2.9      \uReserved Words\n
The \videntifiers\v203. listed below are called reserved words and are reserved for
special significance in the language.  For readability of this manual,  the
reserved words appear in \vlower case\v201. boldface.
    \uabort       declare      generic    of           select\n
    \uabs         delay        goto       or           separate\n
    \uaccept      delta                   others       subtype\n
    \uaccess      digits       if         out\n
    \uall         do           in                      task\n
    \uand                      is         package      terminate\n
    \uarray                               pragma       then\n
    \uat          else                    private      type\n
                \uelsif        limited    procedure\n
                \uend          loop\n
    \ubegin       entry                   raise        use\n
    \ubody        exception               range\n
                \uexit         mod        record       when\n
                                        \urem          while\n
                             \unew        renames      with\n
    \ucase        for          not        return\n
    \uconstant    function     null       reverse      xor\n
A reserved word must not be used as a declared identifier.
\uNotes:\n
Reserved  words  differing only in the use of corresponding upper and lower
case letters are considered as the same (see 2.3).  In some \vattributes\v405.  the
identifier  that appears after the apostrophe is identical to some reserved
word.
2.10     \uAllowable Replacements of Characters\n
The  following  replacements  are  allowed for the vertical bar, sharp, and
quotation \vbasic characters\v201.:
  -  A vertical bar character (|) can be replaced by  an  exclamation  mark
     (!)  where used as a \vdelimiter\v202..
  -  The sharp characters (#) of a \vbased literal\v206. can be replaced by  colons
     (:) provided that the replacement is done for both occurrences.
  -  The quotation characters (") used as \vstring brackets\v208. at both ends of a
     \vstring literal\v208. can be replaced by percent characters (%) provided that
     the  enclosed  sequence of characters contains no quotation character,
     and provided that both string  brackets  are  replaced.   Any  percent
     character  within  the sequence of characters must then be doubled and
     each such doubled percent character is interpreted as a single percent
     \vcharacter value\v312..
These replacements do not change the meaning of the program.
\uNotes:\n
It is recommended that use of the replacements for the vertical bar, sharp,
and quotation characters be restricted to  cases  where  the  corresponding
\vgraphical symbols\v201. are not available.  Note that the vertical bar appears as
a  broken  bar  on  some equipment;  replacement is not recommended in this
case.
The rules given for \videntifiers\v203. and \vnumeric literals\v204. are  such  that  \vlower\v201.
\vcase  and  upper  case\v201.  letters  can  be used indifferently;  these \vlexical\v202.
\velements\v202. can thus be written using only characters of the  basic  character
set.  If a string literal of the predefined type STRING contains characters
that  are  not  in  the basic character set, the same sequence of character
values can be obtained by \vcatenating\v414.  string  literals  that  contain  only
characters  of  the  basic  character set with suitable character constants
declared in the \vpredefined package ASCII\v1700..  Thus the string literal  "AB$CD"
could  be  replaced  by  "AB" & ASCII.DOLLAR & "CD".  Similarly, the string
literal "ABcd" with  lower  case  letters  could  be  replaced  by  "AB"  &
ASCII.LC_C & ASCII.LC_D.
3.       \uDeclarations and Types\n
This  chapter  describes  the  types  in  the  language  and  the rules for
declaring constants, variables, and named numbers.
 3.1    \vDeclarations\v301.
 3.2    \vObjects and Named Numbers\v302.
 3.3    \vTypes and Subtypes\v305.
 3.4    \vDerived Types\v309.
 3.5    \vScalar Types\v310.
 3.6    \vArray Types\v321.
 3.7    \vRecord Types\v325.
 3.8    \vAccess Types\v330.
 3.9    \vDeclarative Parts\v333.
3.1      \uDeclarations\n
The language defines several kinds of entities that  are  declared,  either
explicitly or implicitly, by declarations.  Such an entity can be a \vnumeric\v204.
\vliteral\v204.,  an  object, a discriminant, a \vrecord component\v325., a loop parameter,
an exception, a type, a subtype, a subprogram, a package, a  task  unit,  a
generic  unit,  a  single  entry, an entry family, a formal parameter (of a
subprogram, entry, or \vgeneric subprogram\v1201.), a generic  formal  parameter,  a
named  block  or loop, a labeled statement, or an \voperation\v305. (in particular,
an \vattribute\v405. or an enumeration literal;  see 3.3.3).
There are several forms of declaration.  A basic declaration is a  form  of
declaration defined as follows.
    basic_declaration ::=
         \vobject_declaration\v303.     | \vnumber_declaration\v304.
       | \vtype_declaration\v306.       | subtype_declaration
       | subprogram_declaration | \vpackage_declaration\v701.
       | task_declaration       | generic_declaration
       | exception_declaration  | generic_instantiation
       | \vrenaming_declaration\v805.   | deferred_constant_declaration
Certain  forms  of declaration always occur (explicitly) as part of a basic
declaration;   these  forms  are  \vdiscriminant  specifications\v326.,   \vcomponent\v325.
\vdeclarations\v325.,   \ventry   declarations\v905.,   \vparameter specifications\v601.,  \vgeneric\v1201.
\vparameter declarations\v1201., and \venumeration  literal  specifications\v311..   A  \vloop\v506.
\vparameter  specification\v506.  is  a  form  of  declaration  that occurs only in
certain forms of loop statement.
The remaining forms of declaration are implicit:  the \vname\v401. of a block,  the
name  of  a  loop,  and a statement label are implicitly declared.  Certain
operations are implicitly declared (see 3.3.3).
For each form of declaration the language rules define a certain region  of
text  called  the  \vscope\v802.  of  the  declaration (see 8.2).  Several forms of
declaration associate an \videntifier\v203. with a  declared  entity.   Within  its
scope,  and  only  there,  there are places where it is possible to use the
identifier to refer to the associated declared entity;   these  places  are
defined  by  the \vvisibility\v803. rules (see 8.3).  At such places the identifier
is said to be a name of the entity (its \vsimple name\v401.);  the name is said  to
denote the associated entity.
Certain  forms  of  enumeration literal specification associate a \vcharacter\v207.
\vliteral\v207.  with  the  corresponding  declared  entity.   Certain   forms   of
declaration  associate  an  \voperator  symbol\v601. or some other notation with an
explicitly or implicitly declared operation.
The process by which a  declaration  achieves  its  effect  is  called  the
\velaboration\v333.  of  the  declaration;   this  process  happens  during program
execution.
After its elaboration, a declaration is said to be  elaborated.   Prior  to
the  completion  of its elaboration (including before the elaboration), the
declaration is not yet elaborated.  The elaboration of any declaration  has
always  at least the effect of achieving this change of state (from not yet
elaborated to elaborated).   The  phrase  "the  elaboration  has  no  other
effect"  is  used  in this manual whenever this change of state is the only
effect of elaboration for some form of declaration.  An elaboration process
is also defined for \vdeclarative parts\v333., \vdeclarative items\v333.,  and  compilation
units (see 3.9 and 10.5).
Object,  number,  type,  and  \vsubtype declarations\v307. are described here.  The
remaining basic declarations are described in later chapters.
Note:
The syntax rules use the term identifier for the  first  occurrence  of  an
identifier  in  some form of declaration;  the term simple name is used for
any occurrence of an identifier that already denotes some declared  entity.
3.2      \uObjects and Named Numbers\n
An  object  is  an  entity that contains (has) a value of a given \vtype\v305..  An
object is one of the following:
  -  an object declared by an  object  \vdeclaration\v301.  or  by  a  \vsingle\v901.
     \vtask declaration\v901.,
  -  a \vformal parameter\v601. of a \vsubprogram\v600., \ventry\v905., or \vgeneric subprogram\v1201.,
  -  a generic formal object,
  -  a \vloop parameter\v506.,
  -  an object \vdesignated\v330. by a value of an \vaccess type\v330.,
  -  a \vcomponent\v305. or a \vslice\v403. of another object.
A  number  declaration  is  a  special  form  of  object  declaration  that
associates  an  identifier  with  a  value  of  \vtype\v305.  \vuniversal_integer\v314.  or
\vuniversal_real\v316.
    object_declaration ::=
         identifier_list : [\uconstant\n] \vsubtype_indication\v307. [:= \vexpression\v410.];
       | identifier_list : [\uconstant\n] \vconstrained_array_definition\v321.
                                                         [:= expression];
    number_declaration ::=
         identifier_list : \uconstant\n := universal_static_expression;
    identifier_list ::=  identifier {, identifier}
An  object  declaration  is  called  a  single  object  declaration  if its
identifier list has a single identifier;  it is called  a  multiple  object
declaration if the identifier list has two or more identifiers.  A multiple
object  declaration is equivalent to a sequence of the corresponding number
of single object declarations.   For  each  identifier  of  the  list,  the
equivalent  sequence  has  a  single  object  declaration  formed  by  this
identifier, followed by a colon and by whatever appears at the right of the
colon in the multiple object declaration;  the equivalent  sequence  is  in
the same order as the identifier list.
A  similar  equivalence  applies  also  for  the identifier lists of number
declarations,   component   declarations,   \vdiscriminant\v326.    \vspecifications\v326.,
parameter   specifications,   generic   parameter  declarations,  \vexception\v1101.
\vdeclarations\v1101., and \vdeferred constant declarations\v704..
In the remainder of this  reference  manual,  explanations  are  given  for
declarations  with a single identifier;  the corresponding explanations for
declarations with several identifiers follow from  the  equivalence  stated
above.
Example:
    --  the multiple object declaration
    JOHN, PAUL : PERSON_NAME := new PERSON(SEX => M);  --  see 3.8.1
    --  is  equivalent  to  the two single object declarations in the order
        given
    JOHN : PERSON_NAME := \unew\n PERSON(SEX => M);
    PAUL : PERSON_NAME := \unew\n PERSON(SEX => M);
More details:
 3.2.1  \vObject Declarations\v303.
 3.2.2  \vNumber Declarations\v304.
3.2.1    \uObject Declarations\n
An object \vdeclaration\v301. declares an object whose \vtype\v305. is given  either  by  a
\vsubtype\v305.  indication  or  by  a \vconstrained array definition\v321..  If the object
declaration includes the  \vassignment  compound  delimiter\v502.  followed  by  an
\vexpression\v410.,  the  expression  specifies  an  initial value for the declared
object;  the type of the expression must be that of the object.
The declared object is a constant if the \vreserved word\v211. constant appears  in
the  object  declaration;   the  declaration  must then include an explicit
initialization.   The  value  of  a  constant  cannot  be  modified   after
initialization.   Formal  parameters of \vmode in\v601. of \vsubprograms\v600. and entries,
and \vgeneric formal parameters\v1201. of mode  in,  are  also  constants;   a  loop
parameter  is  a constant within the corresponding loop;  a \vsubcomponent\v305. or
\vslice\v403. of a constant is a constant.
An object that is not a constant is called a variable (in  particular,  the
object declared by an object declaration that does not include the reserved
word  constant  is  a  variable).   The  only ways to change the value of a
variable are either directly by  an  \vassignment\v502.,  or  indirectly  when  the
variable  is updated (see 6.2) by a procedure or \ventry\v905. call statement (this
action can be performed either on the variable itself, on a subcomponent of
the variable, or on  another  variable  that  has  the  given  variable  as
subcomponent).
The \velaboration\v333. of an object declaration proceeds as follows:
(a)  The \vsubtype indication\v307. or the constrained array  definition  is  first
     elaborated.  This establishes the subtype of the object.
(b)  If the object declaration includes  an  explicit  initialization,  the
     initial value  is obtained by evaluating the corresponding expression.
     Otherwise  any  implicit  initial  values  for  the  object or for its
     subcomponents are evaluated.
(c)  The object is created.
(d)  Any initial value (whether explicit or implicit) is  assigned  to  the
     object or to the corresponding subcomponent.
Implicit  initial  values  are  defined  for  objects  declared  by  object
declarations, and for components of such objects, in the  following  cases:
  -  If the type of an object is an \vaccess type\v330., the implicit initial value
     is the null value of the access type.
  -  If the type of an object is a \vtask type\v902.,  the  implicit  initial  (and
     only) value \vdesignates\v330. a corresponding \vtask\v900..
  -  If the type of an object is a type with discriminants and the  subtype
     of the object is constrained, the implicit initial (and only) value of
     each \vdiscriminant\v305. is defined by the subtype of the object.
  -  If the type of an object is a composite  type,  the  implicit  initial
     value  of  each \vcomponent\v305. that has a default expression is obtained by
     \vevaluation\v411. of this expression, unless the component is a  discriminant
     of a constrained object (the previous case).
In  the  case  of  a  component that is itself a composite object and whose
value is defined neither by an explicit initialization  nor  by  a  default
expression,  any  implicit  initial  values for components of the composite
object are defined by the same rules as for a declared object.
The steps (a) to (d) are performed in the order indicated.  For  step  (b),
if  the  default  expression  for  a  discriminant  is evaluated, then this
evaluation  is  performed  before   that   of   default   expressions   for
subcomponents that depend on discriminants, and also before that of default
expressions  that  include  the  name  of the discriminant.  Apart from the
previous rule, the evaluation of default expressions is performed  \vin  some\v108.
\vorder\v108. that is not defined by the language.
The  initialization  of  an  object  (the  declared  object  or  one of its
subcomponents) checks that the initial value belongs to the subtype of  the
object;  for an array object declared by an object declaration, an implicit
subtype  \vconversion\v419. is first applied as for an assignment statement, unless
the object is a constant whose subtype is an unconstrained array type.  The
\vexception CONSTRAINT_ERROR\v1101. is raised if this check fails.
The value of a scalar  variable  is  undefined  after  elaboration  of  the
corresponding object declaration unless an initial value is assigned to the
variable by an initialization (explicitly or implicitly).
If  the  operand of a type conversion or \vqualified expression\v420. is a variable
that has scalar subcomponents with undefined values, then the values of the
corresponding subcomponents of the result are undefined.  The execution  of
a  program  is erroneous if it attempts to evaluate  a scalar variable with
an undefined value.  Similarly, the execution of a program is erroneous  if
it  attempts to apply a \vpredefined operator\v411. to a variable that has a scalar
subcomponent with an undefined value.
Examples of variable declarations:
    COUNT, SUM  : INTEGER;
    SIZE        : INTEGER \urange\n 0 .. 10_ := 0;
    SORTED      : BOOLEAN := FALSE;
    COLOR_TABLE : \uarray\n(1 .. N) \uof\n COLOR;
    OPTION      : BIT_VECTOR(1 .. 10) := (others => TRUE);
Examples of constant declarations:
    LIMIT     : \uconstant\n INTEGER := 10_
    LOW_LIMIT : \uconstant\n INTEGER := LIMIT/10;
    TOLERANCE : \uconstant\n REAL := DISPERSION(1.15);
Note:
The expression  initializing  a  constant  object  need  not  be  a  static
expression  (see  4.9).   In  the  above  examples, LIMIT and LOW_LIMIT are
initialized with static expressions, but TOLERANCE is not if DISPERSION  is
a user-defined function.
3.2.2    \uNumber Declarations\n
A  number  declaration is a special form of constant declaration.  The \vtype\v305.
of  the  static  expression  given  for  the  initialization  of  a  number
declaration   must  be  either  the  type  \vuniversal_integer\v314.  or  the  type
\vuniversal_real\v316..  The constant declared by a number declaration is called  a
named number and has the type of the \vstatic expression\v422..
Note:
The  rules  concerning  expressions  of  a  \vuniversal type\v405. are explained in
section 4.10.  It is a consequence of these rules  that  if  every  \vprimary\v410.
contained  in  the  expression  is  of the type universal_integer, then the
named number is also of this type.  Similarly, if every primary is  of  the
type universal_real, then the named number is also of this type.
Examples of number declarations:
  PI            : \uconstant\n := 3.14159_26536; -- a real number
  TWO_PI        : \uconstant\n := 2.0*PI;        -- a real number
  MAX           : \uconstant\n := 5              -- an integer number
  POWER_16      : \uconstant\n := 2**16;         -- the integer 65_536
  ONE, UN, EINS : \uconstant\n := 1;             -- three different names for 1
3.3      \uTypes and Subtypes\n
A type is characterized by a set of values and a set of operations.
There exist several classes of types.  Scalar types are integer types, real
types,  and  types defined by enumeration of their values;  values of these
types have no components.   Array and \vrecord types\v325. are composite;  a  value
of a composite type consists of component values.  An \vaccess\v330. \vtype\v330. is a type
whose  values provide access to \vobjects\v303.. \vPrivate types\v704. are types for which
the set of possible values is well defined, but not directly  available  to
the  users  of  such types.  Finally, there are \vtask types\v901..  (Private types
are described in chapter 7, task types are  described  in  chapter  9,  the
other classes of types are described in this chapter.)
Certain   record   and   private   types  have  special  components  called
discriminants whose values distinguish alternative forms of values  of  one
of  these  types.   If  a private type has discriminants, they are known to
users of the type.  Hence a private type is only known  by  its  name,  its
discriminants if any, and by the corresponding set of operations.
The  set  of possible values for an object of a given type can be subjected
to a condition that is called a constraint (the case where  the  constraint
imposes  no  restriction  is  also included);  a value is said to satisfy a
constraint if it satisfies the corresponding condition.   A  subtype  is  a
type together with a constraint;  a value is said to belong to a subtype of
a  given  type if it belongs to the type and satisfies the constraint;  the
given type is called the base type of the subtype.  A type is a subtype  of
itself;   such  a subtype is said to be unconstrained:  it corresponds to a
condition that imposes no restriction.  The base type of a type is the type
itself.
The set of operations defined for a subtype of a given  type  includes  the
operations that are defined for the type;  however the \vassignment\v502. operation
to a variable having a given subtype only assigns values that belong to the
subtype.   Additional  operations,  such  as  qualification (in a qualified
expression), are implicitly defined by a \vsubtype declaration\v307..
Certain types have default initial values defined for objects of the  type;
certain  other  types  have  default expressions defined for some or all of
their components.  Certain operations of  types  and  subtypes  are  called
\vattributes\v405.;   these operations are denoted by the form of name described in
section 4.1.4.
The term subcomponent is used in this manual in place of the term component
to indicate either a component, or a  component  of  another  component  or
subcomponent.   Where  other subcomponents are excluded, the term component
is used instead.
A given type must not have a subcomponent whose  type  is  the  given  type
itself.
The  name  of  a  class  of types is used in this manual as a qualifier for
objects and values that have a type of the class considered.  For  example,
the  term "array object" is used for an object whose type is an \varray type\v321.;
similarly, the term "access value" is used for a value of an  access  type.
Note:
The  set of values of a subtype is a subset of the values of the base type.
This subset need not be a proper subset;  it can be an empty subset.
More details:
 3.3.1  \vType Declarations\v306.
 3.3.2  \vSubtype Declarations\v307.
 3.3.3  \vClassification of Operations\v308.
3.3.1  \uType Declarations\n
A type \vdeclaration\v301. declares a \vtype\v305..
    type_declaration ::=  full_type_declaration
       | incomplete_type_declaration | private_type_declaration
    full_type_declaration ::=
         \utype\n \videntifier\v203. [discriminant_part] \uis\n type_definition;
    type_definition ::=
         \venumeration_type_definition\v311. | \vinteger_type_definition\v314.
       | \vreal_type_definition\v316.        | array_type_definition
       | record_type_definition      | access_type_definition
       | derived_type_definition
The  \velaboration\v333.  of a full type declaration consists of the elaboration of
the \vdiscriminant part\v326., if  any  (except  in  the  case  of  the  full  type
declaration  for  an incomplete or \vprivate type declaration\v704.), and of the
elaboration of the type definition.
The types created by the  elaboration  of  distinct  type  definitions  are
distinct  types.   Moreover,  the  elaboration of the type definition for a
\vnumeric\v310. or \vderived type\v309. creates both a \vbase type\v305. and a subtype of the  base
type;   the  same  holds for a \vconstrained array definition\v321. (one of the two
forms of \varray type definition\v321.).
The simple name declared by a full type declaration  denotes  the  declared
type,  unless  the type declaration declares both a base type and a subtype
of the base type, in which case the simple name denotes  the  subtype,  and
the  base  type  is anonymous.  A type is said to be anonymous if it has no
simple name.  For explanatory purposes,  this  reference  manual  sometimes
refers  to an anonymous type by a pseudo-name, written in italics, and uses
such  pseudo-names  at  places  where  the  syntax  normally  requires   an
identifier.
Examples of type definitions:
    (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK)
    range1 .. 72
    \uarray\n(1 .. 10) \uof\n INTEGER
Examples of type declarations:
    \utype\n COLOR  \uis\n (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
    \utype\n COLUMN \uis range\n 1 .. 72;
    \utype\n TABLE  \uis array\n(1 .. 10) \uof\n INTEGER;
\uNotes:\n
Two  type  definitions  always  define two distinct types, even if they are
textually identical.   Thus,  the  array  type  definitions  given  in  the
declarations of A and B below define distinct types.
    A : \uarray\n(1 .. 10) \uof\n BOOLEAN;
    B : \uarray\n(1 .. 10) \uof\n BOOLEAN;
If  A  and  B are declared by a \vmultiple object declaration\v302. as below, their
types are nevertheless different, since the multiple object declaration  is
equivalent to the above two single object declarations.
    A, B : \uarray\n(1 .. 10) \uof\n BOOLEAN;
\vIncomplete  type  declarations\v331. are used for the definition of recursive and
mutually dependent types (see 3.8.1).  Private type declarations  are  used
in  package  specifications  and in \vgeneric parameter declarations\v1201. (see 7.4
and 12.1).
3.3.2    \uSubtype Declarations\n
A \vsubtype\v305. \vdeclaration\v301. declares a subtype.
    subtype_declaration ::=
       \usubtype\n identifier \uis\n subtype_indication;
    subtype_indication ::=  type_mark [constraint]
    type_mark ::= type_name | subtype_name
    constraint ::=
      \vrange_constraint\v310. | \vfloating_point_constraint\v317. | fixed_point_constraint
    | \vindex_constraint\v322. | discriminant_constraint
A  \vtype\v305.  mark denotes a type or a subtype.  If a type mark is the name of a
type,  the  type  mark  denotes  this  type  and  also  the   corresponding
\vunconstrained subtype\v305..  The \vbase type\v305. of a type mark is, by definition, the
base type of the type or subtype denoted by the type mark.
A  subtype  indication defines a subtype of the base type of the type mark.
If an index constraint appears after a type mark in a  subtype  indication,
the  type mark must not already impose an index constraint.  Likewise for a
\vdiscriminant  constraint\v327.,  the  type  mark  must  not  already   impose   a
\vdiscriminant\v305. constraint.
The \velaboration\v333. of a subtype declaration consists of the elaboration of the
subtype  indication.   The  elaboration  of  a subtype indication creates a
subtype.  If the subtype indication does  not  include  a  constraint,  the
subtype is the same as that denoted by the type mark.  The elaboration of a
subtype indication that includes a constraint proceeds as follows:
(a)  The constraint is first elaborated.
(b)  A check is then made that the constraint is compatible with  the  type
     or subtype denoted by the type mark.
The  condition  imposed  by  a  constraint  is the condition obtained after
elaboration of the constraint.  (The rules of  constraint  elaboration  are
such  that  the \vexpressions\v410. and  ranges of constraints are evaluated by the
elaboration of these constraints.)  The rules  defining  compatibility  are
given  for each form of constraint in the appropriate section.  These rules
are such that if a constraint  is  compatible  with  a  subtype,  then  the
condition imposed by the constraint cannot contradict any condition already
imposed  by  the  subtype on its values.  The exception \vCONSTRAINT_ERROR\v1100. is
raised if any check of compatibility fails.
Examples of subtype declarations:
    \usubtype\n RAINBOW   \uis\n COLOR \urange\n RED .. BLUE;        --  see 3.3.1
    \usubtype\n RED_BLUE  \uis\n RAINBOW;
    \usubtype\n INT       \uis\n INTEGER;
    \usubtype\n SMALL_INT \uis\n INTEGER \urange\n -10 .. 10;
    \usubtype\n UP_TO_K   \uis\n COLUMN \urange\n 1 .. K;            --  see 3.3.1
    \usubtype\n SQUARE    \uis\n MATRIX(1 .. 10, 1 .. 10);       --  see 3.6
    \usubtype\n MALE      \uis\n PERSON(SEX => M);               --  see 3.8
Note:
A subtype declaration does not define a new type.
3.3.3    \uClassification of Operations\n
The   set  of  operations  of  a  \vtype\v305.  includes  the  explicitly  declared
\vsubprograms\v600. that have a parameter or result of the type;  such  subprograms
are necessarily declared after the \vtype declaration\v306..
The  remaining  operations  are  each  implicitly declared for a given type
declaration, immediately  after  the  type  definition.   These  implicitly
declared operations comprise the basic operations, the \vpredefined\v411. \voperators\v411.
(see  4.5),  and  \venumeration  literals\v311..   In  the  case  of a derived type
declaration,  the  implicitly  declared  operations  include  any   derived
subprograms.    The   operations  implicitly  declared  for  a  given  type
declaration occur after the type declaration and before the  next  explicit
declaration,  if  any.   The  implicit  declarations of \vderived\v309. \vsubprograms\v309.
occur last.
A basic operation is an operation that is inherent in one of the following:
  -  An \vassignment\v502.  (in  assignment  statements  and  initializations),  an
     \vallocator\v421., a \vmembership test\v411., or a \vshort-circuit control form\v411..
  -  A \vselected component\v404., an \vindexed component\v402., or a \vslice\v403..
  -  A  qualification  (in  \vqualified  expressions\v420.),   an   explicit   type
     \vconversion\v419.,  or  an  implicit  type  conversion  of  a  value  of type
     \vuniversal_integer\v314. or \vuniversal_real\v316.  to  the  corresponding  value  of
     another \vnumeric type\v310..
  -  A numeric \vliteral\v406. (for a \vuniversal type\v405.), the  \vliteral\v330.  \unull\n  (for  an
     access type), a \vstring literal\v208., an \vaggregate\v407., or an \vattribute\v405..
For every type or \vsubtype\v305. T, the following attribute is defined:
T'BASE     The base type of T.  This  attribute  is  allowed  only  as  the
           prefix   of   the  name  of  another  attribute:   for  example,
           T'BASE'FIRST.
Note:
Each literal is an operation  whose  evaluation  yields  the  corresponding
value  (see  4.2).  Likewise, an aggregate is an operation whose evaluation
yields a value of a \vcomposite type\v305. (see 4.3).  Some operations  of  a  type
operate  on  values  of  the  type,  for  example, predefined operators and
certain subprograms and attributes.  The evaluation of some operations of a
type returns a value  of  the  type,  for  example,  literals  and  certain
\vfunctions\v609.,   attributes,   and  predefined  operators.   Assignment  is  an
operation that operates on an \vobject\v303. and a value.  The  evaluation  of  the
operation corresponding to a selected component, an indexed component, or a
slice, yields the object or value denoted by this form of name.
3.4      \uDerived Types\n
A derived type definition defines a new (base) type  whose  characteristics
are  derived from those of a parent type;  the new type is called a derived
type.  A derived type definition further defines a derived  \vsubtype\v305.,  which
is a subtype of the derived \vtype\v305..
    derived_type_definition ::= \unew\n \vsubtype_indication\v307.
The  subtype indication that occurs after the \vreserved word\v211. new defines the
parent subtype.  The parent type is the \vbase type\v305. of  the  parent  subtype.
If  a \vconstraint\v305. exists for the parent subtype, a similar constraint exists
for the  derived  subtype;   the  only  difference  is  that  for  a  \vrange\v310.
\vconstraint\v310.,  and  likewise  for  a  \vfloating\v317. or \vfixed\v319. \vpoint constraint\v319. that
includes a range constraint, the value of each bound  is  replaced  by  the
corresponding  value  of  the  derived  type.   The  characteristics of the
derived type are defined as follows:
  -  The derived type belongs to the same class  of  types  as  the  parent
     type.   The  set  of possible values for the derived type is a copy of
     the set of possible values for the parent type.  If the parent type is
     composite, then the same components exist for the  derived  type,  and
     the subtype of corresponding components is the same.
  -  For each \vbasic operation\v308. of the parent type, there is a  corresponding
     basic  operation  of  the derived type.  Explicit type conversion of a
     value of the parent type into the corresponding value of  the  derived
     type is allowed and vice versa as explained in section 4.6.
  -  For each \venumeration literal\v311. or \vpredefined\v411. \voperator\v411. of the parent type
     there is a corresponding operation for the derived type.
  -  If the parent type is a task type, then for each entry of  the  parent
     type there is a corresponding entry for the derived type.
  -  If a \vdefault expression\v303. exists for a component of an object having the
     parent  type,  then  the  same  default  expression  is  used  for the
     corresponding component of an object having the derived type.
  -  If the parent type is an access type, then the parent and the  derived
     type  share the same \vcollection\v330.;  there is a null \vaccess\v330. \vvalue\v330. for the
     derived type and it is the \vdefault initial value\v330. of that type.
  -  If an explicit \vrepresentation clause\v1301. exists for the parent type and if
     this clause appears before the derived \vtype definition\v306., then there  is
     a  corresponding  representation  clause  (an  implicit  one)  for the
     derived type.
  -  Certain \vsubprograms\v600. that are operations of the parent type are said to
     be derivable.  For each derivable subprogram of the parent type, there
     is a corresponding derived subprogram for the derived type.  Two kinds
     of derivable subprograms exist.  First, if the parent type is declared
     \vimmediately within\v801. the \vvisible part\v702. of a \vpackage\v700.,  then  a  subprogram
     that is itself explicitly declared immediately within the visible part
     becomes  derivable  after  the  end  of  the visible part, if it is an
     operation of the parent type.   (The  explicit  \vdeclaration\v301.  is  by  a
     \vsubprogram   declaration\v601.,   a   \vrenaming  declaration\v805.,  or  a  generic
     instantiation.)  Second, if the parent type is itself a derived  type,
     then  any  subprogram  that  has  been  derived by this parent type is
     further derivable, unless the parent type is declared in  the  visible
     part  of a package and the derived subprogram is hidden by a derivable
     subprogram of the first kind.
Each operation of the derived type is implicitly declared at the  place  of
the  derived  type  declaration.   The \vimplicit declarations\v301. of any derived
subprograms occur last.
The specification  of  a  derived  subprogram  is  obtained  implicitly  by
systematic  replacement  of  the  parent  type  by  the derived type in the
specification of the derivable subprogram.  Any subtype of the parent  type
is  likewise  replaced  by  a  subtype  of  the derived type with a similar
constraint (as for the transformation of a constraint of the parent subtype
into the corresponding constraint of the derived  subtype).   Finally,  any
expression  of  the  parent  type  is  made  to  be  the  operand of a type
\vconversion\v419. that yields a result of the derived type.
Calling a derived subprogram is equivalent  to  calling  the  corresponding
subprogram  of  the  parent type, in which each \vactual\v607. \vparameter\v607. that is of
the derived type is replaced by a type conversion of this actual  parameter
to the parent type (this means that a conversion to the parent type happens
before  the  call for the \vmodes\v601. in and in out;  a reverse conversion to the
derived type happens after the call for the  modes  in  out  and  out,  see
6.4.1).   In  addition, if the result of a called function is of the parent
type, this result is converted to the derived type.
If a derived or \vprivate type\v704. is declared  immediately  within  the  visible
part  of  a  package, then, within this visible part, this type must not be
used as the parent type of a derived type definition.  (For private  types,
see also section 7.4.1.)
For the \velaboration\v333. of a derived type definition, the subtype indication is
first  elaborated,  the  derived  type  is  then  created, and finally, the
derived subtype is created.
\uExamples:\n
    \utype\n LOCAL_COORDINATE \uis new\n COORDINATE;   --  two different types
    \utype\n MIDWEEK \uis new\n DAY \urange\n TUE .. THU;  --  see 3.5.1
    \utype\n COUNTER \uis new\n POSITIVE;              --  same range as POSITIVE
    \utype\n SPECIAL_KEY \uis new\n KEY_MANAGER.KEY;   --  see 7.4.2
    -- the derived subprograms have the following specifications:
    -- \uprocedure\n GET_KEY(K : \uout\n SPECIAL_KEY);
    -- \ufunction\n "<"(X,Y : SPECIAL_KEY) \ureturn\n BOOLEAN;
\uNotes:\n
The rules of derivation of basic operations and enumeration literals  imply
that  the  notation for any \vliteral\v406. or \vaggregate\v407. of the derived type is the
same as for the parent type;  such literals and aggregates are said  to  be
overloaded.   Similarly,  it  follows  that  the  notation  for  denoting a
\vcomponent\v305., a \vdiscriminant\v305., an \ventry\v905., a \vslice\v403., or an \vattribute\v405. is  the  same
for the derived type as for the parent type.
Hiding  of a derived subprogram is allowed even within the same \vdeclarative\v801.
\vregion\v801. (see 8.3).  A derived subprogram hides a  predefined  operator  that
has the same parameter and result type profile (see 6.6).
A  \vgeneric  subprogram  declaration\v1201.  is  not  derivable since it declares a
\vgeneric unit\v1200. rather than a subprogram.  On the other hand, an instantiation
of a \vgeneric subprogram\v1201. is a (nongeneric) subprogram, which is derivable if
it satisfies the requirements for derivability of subprograms.
If the parent type is a \vboolean type\v313., the predefined  relational  operators
of  the  derived  type deliver a result of the predefined type BOOLEAN (see
4.5.2).
If a representation clause is given for the parent type but  appears  after
the  derived  type declaration, then no corresponding representation clause
applies to the derived type;  hence an explicit representation  clause  for
such a derived type is allowed.
For  a  derived subprogram, if a parameter belongs to the derived type, the
subtype of this parameter need not  have  any  value  in  common  with  the
derived subtype.
3.5      \uScalar Types\n
Scalar  types  comprise  \venumeration  types\v311., integer types, and \vreal types\v316..
Enumeration types and \vinteger types\v314. are called discrete types;  each  value
of  a  discrete  type  has  a  position  number  which is an integer value.
Integer types and real types are called numeric types.   All  scalar  types
are  ordered,  that  is,  all \vrelational operators\v411. are predefined for their
values.
    range_constraint ::=  \urange\n range
    range ::=  range_attribute
       | simple_expression .. simple_expression
A range specifies a subset of values of a scalar type.  The range  L  ..  R
specifies  the values from L to R inclusive if the relation L <= R is true.
The values L and R are called the lower bound and upper bound of the range,
respectively.  A value V is said  to  satisfy  a  range  \vconstraint\v305.  if  it
belongs  to  the  range;  the value V is said to belong to the range if the
relations L <= V and V <= R are both TRUE.  A null range  is  a  range  for
which  the  relation R < L is TRUE;  no value belongs to a null range.  The
operators <= and < in the above definitions are the predefined operators of
the scalar type.
If a range constraint is used in a \vsubtype indication\v307., either  directly  or
as  part  of  a  \vfloating\v317. or \vfixed point constraint\v319., the type of the simple
expressions (likewise,  of the bounds of a range  \vattribute\v405.)  must  be  the
same  as the base type of the \vtype mark\v307. of the subtype indication.  A range
constraint is compatible with a subtype if each bound of the range  belongs
to the subtype, or if the range constraint defines a null range;  otherwise
the range constraint is not compatible with the subtype.
The  elaboration  of  a  range constraint consists of the \vevaluation\v411. of the
range.  The evaluation of a range defines its lower  bound  and  its  upper
bound.   If  \vsimple  expressions\v410.  are  given  to  specify  the  bounds, the
evaluation of the range evaluates these simple expressions  in  some  order
that is not defined by the language.
Attributes
For  any scalar type T or for any subtype T of a scalar type, the following
attributes are defined:
T'FIRST     Yields the lower bound of T.  The value of this  attribute  has
            the same type as T.
T'LAST      Yields the upper bound of T.  The value of this  attribute  has
            the same type as T.
Note:
Indexing and iteration rules use values of discrete types.
More details:
 3.5.1  \vEnumeration Types\v311.
 3.5.2  \vCharacter Types\v312.
 3.5.3  \vBoolean Types\v313.
 3.5.4  \vInteger Types\v314.
 3.5.5  \vOperations of Discrete Types\v315.
 3.5.6  \vReal Types\v316.
 3.5.7  \vFloating Point Types\v317.
 3.5.8  \vOperations of Floating Point Types\v318.
 3.5.9  \vFixed Point Types\v319.
 3.5.10 \vOperations of fixed point types\v320.
3.5.1  Enumeration Types
An enumeration \vtype definition\v306. defines an enumeration \vtype\v305..
 enumeration_type_definition ::=
  (enumeration_literal_specification {, enumeration_literal_specification})
 enumeration_literal_specification ::=  enumeration_literal
 enumeration_literal ::=  identifier | character_literal
The  identifiers  and  \vcharacter  literals\v207.  listed  by  an enumeration type
definition must be distinct.  Each enumeration literal specification is the
\vdeclaration\v301. of the corresponding enumeration literal:  this declaration  is
equivalent  to  the declaration of a parameterless \vfunction\v609., the \vdesignator\v601.
being the enumeration literal, and the result type  being  the  enumeration
type.   The  \velaboration\v333.  of  an  enumeration  type  definition  creates an
enumeration type;  this elaboration  includes  that  of  every  enumeration
literal specification.
Each  enumeration  literal  yields  a  different  enumeration  value.   The
predefined order relations between enumeration values follow the  order  of
corresponding  \vposition  numbers\v310..   The position number of the value of the
first listed enumeration literal is zero;  the  position  number  for  each
other enumeration literal is one more than for its predecessor in the list.
If  the  same identifier or character literal is specified in more than one
enumeration type definition, the corresponding  literals  are  said  to  be
\voverloaded\v610..  At any place where an overloaded enumeration literal occurs in
the  text  of  a  program,  the  type  of  the  enumeration literal must be
determinable from the context (see 8.7).
\uExamples:\n
  \utype\n DAY    \uis\n (MON, TUE, WED, THU, FRI, SAT, SUN);
  \utype\n SUIT   \uis\n (CLUBS, DIAMONDS, HEARTS, SPADES);
  \utype\n GENDER \uis\n (M, F);
  \utype\n LEVEL  \uis\n (LOW, MEDIUM, URGENT);
  \utype\n COLOR  \uis\n (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
  \utype\n LIGHT  \uis\n (RED, AMBER, GREEN); -- RED and GREEN are overloaded
  \utype\n HEXA   \uis\n ('A', 'B', 'C', 'D', 'E', 'F');
  \utype\n MIXED  \uis\n ('A', 'B', '*', B, NONE, '?', '%');
  \subtype\n WEEKDAY \uis\n DAY   \urange\n MON .. FRI;
  \subtype\n MAJOR   \uis\n SUIT  \urange\n HEARTS .. SPADES;
  \subtype\n RAINBOW \uis\n COLOR \urange\n RED .. BLUE;  --  the color RED, not the
                                                   light
Note:
If an enumeration literal occurs in  a  context  that  does  not  otherwise
suffice  to  determine  the  type of the literal, then qualification by the
\vname\v401. of the enumeration type is one way to resolve the ambiguity (see 8.7).
3.5.2    \uCharacter Types\n
An \venumeration type\v311. is said to be a character \vtype\v305. if at least one  of  its
enumeration \vliterals\v406. is a \vcharacter literal\v207..  The predefined type CHARACTER
is  a  character  type  whose  values  are  the 128 characters of the ASCII
character set.  Each of the 95 \vgraphic characters\v201. of this character set  is
denoted by the corresponding character literal.
Example:
    \utype\n ROMAN_DIGIT \uis\n ('I', 'V', 'X', 'L', 'C', 'D', 'M');
\uNotes:\n
The \vpredefined package ASCII\v201. includes the \vdeclaration\v301. of constants denoting
control  characters  and  of \vconstants\v303. denoting graphic characters that are
not in the basic character set.
A conventional character set such as EBCDIC can be declared as a  character
type;   the  internal  codes  of  the  characters  can  be  specified by an
enumeration representation clause as explained in section 13.3.
3.5.3    \uBoolean Types\n
There is a predefined enumeration type named BOOLEAN.  It contains the  two
literals  FALSE and TRUE ordered with the relation FALSE < TRUE.  A boolean
type is either the type BOOLEAN or a type  that  is  \vderived\v309.,  directly  or
indirectly, from a boolean \vtype\v305..
3.5.4    \uInteger Types\n
An integer \vtype definition\v306. defines an integer  type  whose  set  of  values
includes at least those of the specified range.
    integer_type_definition ::=  \vrange_constraint\v310.
If  a range constraint is used as an integer type definition, each \vbound of\v310.
\vthe range\v310. must be defined by a \vstatic expression\v422. of some integer type,  but
the  two  bounds need not have the same integer type.  (Negative bounds are
allowed.)
A type declaration of the form:
    \utype\n T \uis range\n L .. R;
is, by definition, equivalent to the following declarations:
    \utype\n integer_type \uis new\n predefined_integer_type;
    \usubtype\n T \uis\n integer_type \urange\n integer_type(L) .. integer_type(R);
where integer_type is an \vanonymous type\v306., and where the  predefined  integer
type  is  implicitly  selected  by the implementation, so as to contain the
values L to R inclusive.  The integer \vtype declaration\v306. is illegal  if  none
of  the  predefined  integer  types  satisfies  this requirement, excepting
\vuniversal_integer\v401..  The elaboration of the declaration of an  integer  type
consists   of   the   elaboration   of  the  equivalent  type  and  \vsubtype\v307.
\vdeclarations\v307..
The predefined integer types include the type INTEGER.   An  implementation
may  also  have  predefined  types  such as SHORT_INTEGER and LONG_INTEGER,
which have (substantially) shorter and longer  ranges,  respectively,  than
INTEGER.   The  range  of each of these types must be symmetric about zero,
excepting an extra negative value which may exist in some  implementations.
The base type of each of these types is the type itself.
\vInteger  literals\v204.  are the \vliterals\v406. of an anonymous predefined integer type
that is called universal_integer in this reference manual.   Other  integer
types  have  no  literals.   However, for each integer type there exists an
implicit \vconversion\v419.  that  converts  a  universal_integer  value  into  the
corresponding  value (if any) of the integer type.  The circumstances under
which these implicit conversions are invoked are described in section  4.6.
The  position  number of an integer value is the corresponding value of the
type universal_integer.
The same arithmetic operators are predefined for  all  integer  types  (see
4.5).   The  exception  NUMERIC_ERROR  is  raised  by  the  execution of an
operation (in particular an implicit conversion) that  cannot  deliver  the
correct  result  (that  is,  if the value corresponding to the mathematical
result is not a  value of the integer type).  However, an implementation is
not required to raise the \vexception NUMERIC_ERROR\v1101. if the operation is  part
of a larger expression whose result can be computed correctly, as described
in section 11.6.
\uExamples:\n
    \utype\n PAGE_NUM  \uis range\n 1 .. 2_
    \utype\n LINE_SIZE \uis range\n 1 .. MAX_LINE_SIZE;
    \usubtype\n SMALL_INT   \uis\n INTEGER   \urange\n -10 .. 10;
    \usubtype\n COLUMN_PTR  \uis\n LINE_SIZE \urange\n 1 .. 10;
    \usubtype\n BUFFER_SIZE \uis\n INTEGER   \urange\n 0 .. MAX;
\uNotes:\n
The name declared by an integer type declaration is a subtype name.  On the
other  hand,  the  \vpredefined  operators\v411. of an integer type deliver results
whose range is defined by the \vparent predefined type\v309.;  such a  result  need
not  \vbelong to the declared subtype\v305., in which case an attempt to assign the
result  to  a  variable  of  the  integer  subtype  raises  the   exception
\vCONSTRAINT_ERROR\v1101..
The  smallest  (most  negative)  value  supported by the predefined integer
types of an implementation is  the  named  number  SYSTEM.MIN_INT  and  the
largest (most positive) value is SYSTEM.MAX_INT (see 13.7).
3.5.5    \uOperations of Discrete Types\n
The basic \voperations\v305. of a discrete type include the operations involved  in
assignment,  the  \vmembership  tests\v411., and qualification;  for a \vboolean type\v313.
they include the short-circuit control forms;  for  an  \vinteger  type\v314.  they
include  the  explicit  \vconversion\v419.  of values of other \vnumeric types\v310. to the
integer  type,  and  the  implicit  conversion  of  values  of   the   type
\vuniversal_integer to the type\v314..
Finally, for every \vdiscrete type\v310. or subtype T, the basic operations include
the  attributes  listed  below.   In this presentation, T is referred to as
being  a  subtype  (the  subtype  T)  for  any  property  that  depends  on
\vconstraints\v305. imposed by T;  other properties are stated in terms of the \vbase\v305.
\vtype\v305. of T.
The first group of attributes yield characteristics of the subtype T.  This
group  includes  the  attribute  BASE (see 3.3.2), the attributes FIRST and
LAST (see 3.5), the representation attribute SIZE (see  13.7.2),  and   the
attribute WIDTH defined as follows:
T'WIDTH     Yields the maximum image length over all values of the  subtype
            T  (the  image  is  the  sequence of characters returned by the
            attribute IMAGE, see below).  Yields zero  for  a  null  range.
            The  value  of this attribute is of the type universal_integer.
All attributes of the second group are \vfunctions\v609. with a  single  parameter.
The corresponding actual parameter is indicated below by X.
T'POS       This attribute is a function.  The parameter X must be a  value
            of   the  base  type  of  T.   The  result  type  is  the  type
            universal_integer.  The result is the \vposition  number\v310.  of  the
            value of the parameter.
T'VAL       This attribute is a special function with  a  single  parameter
            which  can be of any integer type.  The result type is the base
            type of T.  The result is the value whose  position  number  is
            the  universal_integer value corresponding to X.  The exception
            \vCONSTRAINT_ERROR\v1101.  is  raised  if  the  universal_integer  value
            corresponding  to  X is not in the range T'POS(T'BASE'FIRST) ..
            T'POS(T'BASE'LAST).
T'SUCC      This attribute is a function.  The parameter X must be a  value
            of  the base type of T.  The result type is the base type of T.
            The result is the value whose position number  is  one  greater
            than  that of X.  The exception CONSTRAINT_ERROR is raised if X
            equals T'BASE'LAST.
T'PRED      This attribute is a function.  The parameter X must be a  value
            of  the base type of T.  The result type is the base type of T.
            The result is the value whose position number is one less  than
            that  of  X.   The  \vexception  CONSTRAINT_ERROR\v1101.  is raised if X
            equals T'BASE'FIRST.
T'IMAGE     This attribute is a function.  The parameter X must be a  value
            of  the base type of T.  The result type is the predefined type
            STRING.  The result is the image of the value of X, that is,  a
            sequence  of characters representing the value in display form.
            The image of an integer  value  is  the  corresponding  decimal
            literal;   without  underlines,  leading  zeros,  exponent,  or
            trailing spaces;  but with a single leading character  that  is
            either  a  minus sign or a space.  The lower bound of the image
            is one.
            The image of an enumeration value is either  the  corresponding
            \videntifier\v203. in upper case or the corresponding \vcharacter literal\v207.
            (including  the two apostrophes);  neither leading nor trailing
            spaces are included.  The image of a character C, other than  a
            \vgraphic   character\v201.,   is   implementation-defined;   the  only
            requirement is that the  image  must  be  such  that  C  equals
            CHARACTER'VALUE(CHARACTER'IMAGE(C)).
T'VALUE     This attribute is a function.  The parameter X must be a  value
            of  the  predefined  type  STRING.  The result type is the base
            type of T.  Any leading and any trailing spaces of the sequence
            of characters that corresponds to the parameter are ignored.
            For an enumeration type, if the sequence of characters has  the
            syntax of an \venumeration literal\v311. and if this literal exists for
            the base type of T, the result is the corresponding enumeration
            value.   For an integer type, if the sequence of characters has
            the syntax of an  integer  literal,  with  an  optional  single
            leading character that is a plus or minus sign, and if there is
            a corresponding value in the base type of T, the result is this
            value.   In  any  other case, the exception CONSTRAINT_ERROR is
            raised.
In addition, the attributes A'SIZE and A'ADDRESS are defined for an  \vobject\v302.
A of a discrete type (see 13.7.2).
Besides the \vbasic operations\v308., the operations of a discrete type include the
predefined relational operators.  For enumeration types, operations include
enumeration literals.  For boolean types, operations include the predefined
unary  logical negation \voperator not\v411., and the predefined \vlogical operators\v411..
For integer types, operations include the predefined arithmetic  operators:
these  are  the  \vbinary and unary adding operators\v411. - and +, all \vmultiplying\v411.
\voperators\v411., the unary \voperator abs\v411., and the \vexponentiating operator\v411..
The operations of a subtype are the corresponding operations  of  its  base
type   except   for   the   following:    \vassignment\v502.,   membership   tests,
qualification, explicit type \vconversions\v419., and the \vattributes\v405. of  the  first
group;   the  effect  of  each  of  these operations depends on the subtype
(assignments, membership tests, qualifications, and conversions  involve  a
subtype check;  attributes of the first group yield a characteristic of the
subtype).
\uNotes:\n
For  a  subtype of a discrete type, the results delivered by the attributes
SUCC, PRED, VAL, and VALUE need not belong to the subtype;  similarly,  the
actual  parameters  of  the  attributes POS, SUCC, PRED, and IMAGE need not
belong to the subtype.  The  following  relations  are  satisfied  (in  the
absence of an exception) by these attributes:
    T'POS(T'SUCC(X)) = T'POS(X) + 1
    T'POS(T'PRED(X)) = T'POS(X) - 1
    T'VAL(T'POS(X))  = X
    T'POS(T'VAL(N))  = N
\uExamples:\n
    --  For the types and subtypes declared in section 3.5.1 we have:
    --  COLOR'FIRST   = WHITE,   COLOR'LAST   = BLACK
    --  RAINBOW'FIRST = RED,     RAINBOW'LAST = BLUE
    --  COLOR'SUCC(BLUE) = RAINBOW'SUCC(BLUE) = BROWN
    --  COLOR'POS(BLUE)  = RAINBOW'POS(BLUE)  = 4
    --  COLOR'VAL(0)     = RAINBOW'VAL(0)     = WHITE
3.5.6    \uReal Types\n
Real \vtypes\v305. provide approximations to the real numbers, with relative bounds
on  errors  for  floating  point  types, and with absolute bounds for fixed
point types.
    real_type_definition ::=
       \vfloating_point_constraint\v317. | fixed_point_constraint
A set of numbers called model numbers is associated with  each  real  type.
Error  bounds  on the \vpredefined operations\v308. are given in terms of the model
numbers.  An implementation of the type must include at least  these  model
numbers and represent them exactly.
An  implementation-dependent  set  of  numbers, called the safe numbers, is
also associated with each real type.  The set of safe  numbers  of  a  real
type must include at least the set of model numbers of the type.  The range
of  safe  numbers  is allowed to be larger than the range of model numbers,
but error bounds on the predefined operations for safe numbers are given by
the same rules as  for  model  numbers.   Safe  numbers  therefore  provide
guaranteed error bounds for operations on an implementation-dependent range
of  numbers;   in  contrast, the range of model numbers depends only on the
real \vtype definition\v306. and is therefore independent of the implementation.
Real \vliterals\v204. are the \vliterals\v406. of an anonymous predefined real type that is
called universal_real in this reference manual.  Other real types  have  no
literals.  However, for each real type, there exists an implicit \vconversion\v419.
that  converts  a  universal_real value into a value of the real type.  The
conditions under which these implicit conversions are invoked are described
in section 4.6.   If  the  universal_real  value  is  a  safe  number,  the
implicit conversion delivers the corresponding value;  if it belongs to the
range  of  safe  numbers but is not a safe number, then the converted value
can be any value within the range defined by the safe  numbers  next  above
and below the universal_real value.
The  execution of an operation that yields a value of a real type may raise
the \vexception NUMERIC_ERROR\v1101., as explained in section 4.5.7,  if  it  cannot
deliver a correct result (that is, if the value corresponding to one of the
possible  mathematical  results  does  not  belong  to  the  range  of safe
numbers);  in particular, this exception  can  be  raised  by  an  implicit
conversion.   However,  an  implementation  is  not  required  to raise the
exception NUMERIC_ERROR if the operation is part  of  a  larger  expression
whose result can be computed correctly (see 11.6).
The  \velaboration\v333.  of a real type definition includes the elaboration of the
floating or \vfixed point constraint\v319. and creates a real type.
Note:
An algorithm written to rely only upon  the  minimum  numerical  properties
guaranteed  by  the  type  definition  for  model  numbers will be portable
without further precautions.
3.5.7    \uFloating Point Types\n
For  floating  point  \vtypes\v305.,  the  \verror  bound\v316.  is specified as a relative
precision by giving the required  minimum  number  of  significant  decimal
digits.
    floating_point_constraint ::=
       floating_accuracy_definition [range_constraint]
    floating_accuracy_definition ::=  \udigits\n static_simple_expression
The  minimum number of significant decimal digits is specified by the value
of the static \vsimple expression\v410. of the floating accuracy definition.   This
value  must belong to some \vinteger type\v314. and must be positive (nonzero);  it
is denoted by D in the remainder of this section.  If  the  floating  point
constraint  is  used  as  a  real  type  definition  and  includes  a range
constraint, then each \vbound of the  range\v310.  must  be  defined  by  a \vstatic\v422.
\vexpression\v422.  of  some  real  type, but the two bounds need not have the same
\vreal type\v316..
For a given radix, the following canonical form is defined for any floating
point \vmodel number\v316. other than zero:
    sign * mantissa * (radix ** \vexponent\v205.)
In this form: sign is either +1 or -1;  mantissa is expressed in  a  number
base  given by radix; and exponent is an integer number (possibly negative)
such that the integer part of mantissa is zero and the first digit  of  its
fractional part is not a zero.
The  specified  number  D  is the minimum number of decimal digits required
after the point in the decimal mantissa (that is, if radix  is  ten).   The
value  of D in turn determines a corresponding number B that is the minimum
number of binary digits required after the point  in  the  binary  mantissa
(that is, if radix is two).  The number B associated with D is the smallest
value  such  that the relative precision of the binary form is no less than
that specified for the decimal form.  (The number B  is  the  integer  next
above (D*log(10)/log(2)) + 1.)
The  model  numbers defined by a floating accuracy definition comprise zero
and all numbers whose binary canonical form has exactly B digits after  the
point  in  the  mantissa  and  an  exponent in the range -4*B .. +4*B.  The
guaranteed minimum accuracy of \voperations\v305.  of  a  floating  point  type  is
defined in terms of the model numbers of the floating point constraint that
forms the corresponding \vreal type definition\v316. (see 4.5.7).
The   predefined   floating   point  types  include  the  type  FLOAT.   An
implementation may also have  predefined  types  such  as  SHORT_FLOAT  and
LONG_FLOAT,   which   have   (substantially)   less   and   more  accuracy,
respectively, than FLOAT.  The base type of each predefined floating  point
type  is  the  type  itself.  The model numbers of each predefined floating
point type are defined in terms of the number D of decimal digits  returned
by the attribute DIGITS (see 3.5.8).
For  each  predefined  floating point type (consequently also for each \vtype\v309.
\vderived\v309. therefrom), a set of \vsafe numbers\v316. is defined as follows.  The  safe
numbers  have  the same number B of mantissa \vdigits\v201. as the model numbers of
the type  and  have  an  exponent  in  the  range  -E  ..  +E  where  E  is
implementation-defined  and  at  least  equal  to the 4*B of model numbers.
(Consequently, the safe numbers include  the  model  numbers.)   The  rules
defining  the  accuracy of operations with model and safe numbers are given
in section 4.5.7.  The safe numbers of a subtype  are  those  of  its  base
type.
A floating point \vtype declaration\v306. of one of the two forms (that is, with or
without the optional range constraint indicated by the square brackets):
    \utype\n T \uis digits\n D [\urange\n L .. R];
is, by definition, equivalent to the following declarations:
    \utype\n floating_point_type \uis new\n predefined_floating_point_type;
    \usubtype\n T \uis\n floating_point_type \udigits\n D
       [\urange\n floating_point_type(L) .. floating_point_type(R)];
where  floating_point_type  is  an \vanonymous type\v306., and where the predefined
floating point type is implicitly selected by the  implementation  so  that
its  model numbers include the model numbers defined by D;  furthermore, if
a range L .. R is supplied, then both L and R must belong to the  range  of
safe  numbers.   The  floating  point declaration is illegal if none of the
predefined floating point types  satisfies  these  requirements,  excepting
universal_real.   The  maximum  number of digits that can be specified in a
floating accuracy definition is given by the system-dependent named  number
SYSTEM.MAX_DIGITS (see 13.7.1).
The  \velaboration\v301.  of  a  floating  point  type  declaration consists of the
elaboration of the equivalent type and \vsubtype declarations\v307..
If a floating point constraint follows a \vtype mark\v307. in a \vsubtype indication\v307.,
the type mark must denote a floating point type or \vsubtype\v305..   The  floating
point  constraint  is  \vcompatible\v307.  with  the type mark only if the number D
specified in the floating accuracy  definition  is  not  greater  than  the
corresponding  number  D  for the type or subtype denoted by the type mark.
Furthermore, if the floating point constraint includes a range  constraint,
the  floating point constraint is compatible with the type mark only if the
range constraint is, itself, compatible with the type mark.
The elaboration of such a subtype indication includes  the  elaboration  of
the range constraint, if there is one;  it creates a floating point subtype
whose  model  numbers  are  defined  by the corresponding floating accuracy
definition.  A value of a floating point type belongs to a  floating  point
subtype if and only if it \vbelongs to the range defined by the subtype\v305..
The  same  \varithmetic operators\v315. are predefined for all floating point types
(see 4.5).
\uNotes:\n
A range constraint is allowed  in  a  floating  point  subtype  indication,
either  directly  after  the  type  mark,  or  as  part of a floating point
constraint.  In either case the bounds of the range must belong to the base
type of the type mark (see  3.5).   The  imposition  of  a  floating  point
constraint on a type mark in a subtype indication cannot reduce the allowed
range  of  values unless it includes a range constraint (the range of model
numbers that correspond to the specified number of digits  can  be  smaller
than  the  range  of  numbers of the type mark).  A value that belongs to a
floating point subtype need not be a model number of the subtype.
\uExamples:\n
    \utype\n COEFFICIENT \uis digits\n 10 range -1.0 .. 1.0;
    \utype\n REAL \uis digits\n 8;
    \utype\n MASS \uis digits\n 7 \urange\n 0.0 .. 1.0E35;
    \usubtype\n SHORT_COEFF \uis\n COEFFICIENT \udigits\n 5;
                                         --  a subtype with less accuracy
    \usubtype\n PROBABILITY \uis\n REAL \urange\n 0.0 .. 1.0;
                                         --  a subtype with a smaller range
Notes on the examples:
The implemented accuracy for COEFFICIENT  is  that  of  a  predefined  type
having  at least 10 digits of precision.  Consequently the specification of
5 digits of precision for the subtype SHORT_COEFF is allowed.  The  largest
model number for the type MASS is approximately 1.27E30 and hence less than
the  specified  upper bound (1.0E35).  Consequently the declaration of this
type is legal only if this upper bound is in the range of the safe  numbers
of  a predefined floating point type having at least 7 digits of precision.
3.5.8    \uOperations of Floating Point Types\n
The  \vbasic  operations\v308.  of  a  \vfloating  point  type\v317. include the \voperations\v305.
involved in  \vassignment\v502.,  \vmembership  tests\v411.,  qualification,  the  explicit
\vconversion\v419. of values of other \vnumeric types\v310. to the floating point \vtype\v305., and
the  implicit  conversion of values of the type \vuniversal_real\v316. to the type.
In addition, for  every  floating  point  type  or  \vsubtype\v305.  T,  the  basic
operations include the \vattributes\v405. listed below.  In this presentation, T is
referred  to  as  being  a  subtype  (the  subtype T) for any property that
depends on \vconstraints\v305. imposed by T;  other properties are stated in  terms
of the \vbase type\v305. of T.
The  first group of attributes yield characteristics of the subtype T.  The
attributes of this group are the attribute BASE (see 3.3.2), the attributes
FIRST and LAST (see 3.5), the representation attribute SIZE  (see  13.7.2),
and the following attributes:
T'DIGITS     Yields the number of decimal \vdigits\v201. in the decimal mantissa of
             \vmodel  numbers\v316.  of  the subtype T.  (This attribute yields the
             number D of section 3.5.7.)  The value of this attribute is of
             the \vtype universal_integer\v314..
T'MANTISSA   Yields the number of binary digits in the binary  mantissa  of
             model  numbers  of  the subtype T.  (This attribute yields the
             number B of section 3.5.7.)  The value of this attribute is of
             the type universal_integer.
T'EPSILON    Yields the absolute value of the difference between the  model
             number 1.0 and the next model number above, for the subtype T.
             The value of this attribute is of the type universal_real.
T'EMAX       Yields the largest exponent value in the binary canonical form
             of model numbers of the subtype T.  (This attribute yields the
             product 4*B of section 3.5.7.)  The value of this attribute is
             of the type  universal_integer.
T'SMALL      Yields the smallest positive (nonzero)  model  number  of  the
             subtype  T.   The  value  of  this  attribute  is  of the type
             universal_real.
T'LARGE      Yields the largest positive model number  of  the  subtype  T.
             The value of this attribute is of the type universal_real.
The  attributes  of the second group include the following attributes which
yield characteristics of the safe numbers:
T'SAFE_EMAX  Yields the largest exponent value in the binary canonical form
             of safe numbers of the base type of T.  (This attribute yields
             the number E of section 3.5.7.)  The value of  this  attribute
             is of the type universal_integer.
T'SAFE_SMALL Yields the smallest positive (nonzero) safe number of the base
             type  of  T.   The  value  of  this  attribute  is of the type
             universal_real.
T'SAFE_LARGE Yields the largest positive safe number of the base type of T.
             The value of this attribute is of the type universal_real.
In addition, the attributes A'SIZE and A'ADDRESS are defined for an  \vobject\v302.
A  of a floating point type (see 13.7.2).  Finally, for each floating point
type there are machine-dependent attributes that are not related  to  model
numbers  and  safe  numbers.   They correspond to the attribute designators
MACHINE_RADIX,      MACHINE_MANTISSA,      MACHINE_EMAX,      MACHINE_EMIN,
MACHINE_ROUNDS, and MACHINE_OVERFLOWS (see 13.7.3).
Besides  the  basic  operations,  the  operations  of a floating point type
include the \vrelational operators\v411., and the following  predefined  \varithmetic\v315.
\voperators\v315.:   the binary and \vunary adding operators\v411. - and +, the \vmultiplying\v411.
operators * and /, the unary \voperator abs\v411., and the \vexponentiating\v411. \voperator\v411..
The operations of a subtype are the corresponding operations  of  the  type
except  for  the  following:   assignment, membership tests, qualification,
explicit conversion, and the attributes of the first group;  the effects of
these operations are redefined in terms of the subtype.
\uNotes:\n
The  attributes  EMAX,  SMALL,  LARGE,  and  EPSILON   are   provided   for
convenience.   They  are all related to MANTISSA by the following formulas:
    T'EMAX    = 4*T'MANTISSA
    T'EPSILON = 2.0**(1 - T'MANTISSA)
    T'SMALL   = 2.0**(-T'EMAX - 1)
    T'LARGE   = 2.0**T'EMAX * (1.0 - 2.0**(-T'MANTISSA))
The attribute MANTISSA, giving the number of binary digits in the mantissa,
is itself related to DIGITS.  The  following  relations  hold  between  the
characteristics of the model numbers and those of the \vsafe numbers\v311.:
    T'BASE'EMAX  <= T'SAFE_EMAX
    T'BASE'SMALL >= T'SAFE_SMALL
    T'BASE'LARGE <= T'SAFE_LARGE
The attributes T'FIRST and T'LAST need not yield model or safe numbers.  If
a  certain  number  of  digits is specified in the declaration of a type or
subtype T, the attribute T'DIGITS yields this number.
3.5.9    \uFixed Point Types\n
For fixed point types, the \verror bound\v316. is specified as an  absolute  value,
called the delta of the fixed point \vtype\v305..
    fixed_point_constraint ::=
       fixed_accuracy_definition [range_constraint]
    fixed_accuracy_definition ::=  \udelta\n static_simple_expression
The  \udelta\n is specified by the value of the static \vsimple expression\v410. of the
fixed accuracy definition.  This value must belong to some  real  type  and
must  be  positive  (nonzero).   If the fixed point constraint is used as a
\vreal type\v316. definition, then it must include a range constraint;  each  bound
of  the specified range must be defined by a \vstatic expression\v422. of some real
type but the two bounds need not have the same real  type.   If  the  fixed
point  constraint  is used in a \vsubtype indication\v307., the range constraint is
optional.
A canonical form is defined for any fixed point  \vmodel  number\v316.  other  than
zero.   In  this  form:   sign  is either +1 or -1;  mantissa is a positive
(nonzero) integer;  and any  model  number  is  a  multiple  of  a  certain
positive real number called small, as follows:
    sign * mantissa * small
For the model numbers defined by a fixed point constraint, the number small
is chosen as the largest power of two that is not greater than the delta of
the  fixed  accuracy  definition.  Alternatively, it is possible to specify
the value of small by a \vlength clause\v1302.  (see  13.2),  in  which  case  model
numbers  are  multiples  of  the  specified  value.  The guaranteed minimum
accuracy of \voperations\v305. of a fixed point type is defined  in  terms  of the
model  numbers  of  the fixed point constraint that forms the corresponding
real type definition (see 4.5.7).
For a fixed point constraint that includes a range  constraint,  the  model
numbers  comprise  zero  and  all  multiples of small whose mantissa can be
expressed using exactly B binary digits, where the value of B is chosen  as
the  smallest integer number for which each \vbound of the specified range\v310. is
either a model number or lies at most small distant from  a  model  number.
For a fixed point constraint that does not include a range constraint (this
is  only  allowed  after  a  \vtype mark\v307., in a subtype indication), the model
numbers are defined by the delta of the fixed accuracy  definition  and  by
the range of the subtype denoted by the type mark.
An  implementation  must have at least one anonymous predefined fixed point
type.  The \vbase type\v305. of each such fixed point type is the type itself.  The
model numbers of each predefined fixed point type  comprise  zero  and  all
numbers for which mantissa (in the canonical form) has the number of binary
digits  returned  by the attribute MANTISSA, and for which the number small
has the value returned by the attribute SMALL.
A fixed point \vtype declaration\v306. of the form:
    \utype\n T \uis delta\n D \urange\n L .. R;
is, by definition, equivalent to the following declarations:
    \utype\n fixed_point_type \uis new\n predefined_fixed_point_type;
    \usubtype\n T \uis\n fixed_point_type
       \urange\n fixed_point_type(L) .. fixed_point_type(R);
In these declarations, fixed_point_type  is  an  \vanonymous  type\v306.,  and  the
predefined fixed point type is implicitly selected by the implementation so
that its model numbers include the model numbers defined by the fixed point
constraint  (that  is,  by  D,  L,  and  R, and possibly by a length clause
specifying small).
The fixed point declaration is illegal  if  no  predefined  type  satisfies
these  requirements.   The \vsafe numbers\v316. of a fixed point type are the model
numbers of its base type.
The  \velaboration\v333.  of  a  fixed  point  type  declaration  consists  of  the
elaboration of the equivalent type and \vsubtype declarations\v307..
If  the fixed point constraint follows a type mark in a subtype indication,
the type mark must denote a fixed point type or subtype.  The  fixed  point
constraint  is \vcompatible\v307. with the type mark only if the delta specified by
the fixed accuracy definition is not smaller than the delta for the type or
subtype denoted  by  the  type  mark.   Furthermore,  if  the  fixed  point
constraint  includes  a  range  constraint,  the  fixed point constraint is
compatible with the type mark only if  the  range  constraint  is,  itself,
compatible with the type mark.
The  elaboration  of  such a subtype indication includes the elaboration of
the range constraint, if there is one;  it creates a  fixed  point  subtype
whose model numbers are defined by the corresponding fixed point constraint
and  also  by the length clause specifying small, if there is one.  A value
of a fixed point type \vbelongs to a fixed point subtype\v305. if and  only  if  it
belongs to the range defined by the subtype.
The same \varithmetic operators\v310. are predefined for all fixed point types (see
4.5).  Multiplication and division of fixed point values deliver results of
an  anonymous predefined fixed point type that is called universal_fixed in
this reference manual;  the accuracy of this type is arbitrarily fine.  The
values of this type must be converted explicitly to some \vnumeric type\v310..
\uNotes:\n
If S is a subtype of a fixed point type or subtype T, then the set of model
numbers of S is a subset of those of T.  If a length clause has been  given
for  T,  then both S and T have the same value for small.  Otherwise, since
small is a power of two, the small  of  S  is  equal  to  the  small  of  T
multiplied by a nonnegative power of two.
A  range  constraint is allowed in a fixed point subtype indication, either
directly after the type mark, or as part of a fixed point  constraint.   In
either  case  the  bounds  of the range must belong to the base type of the
type mark (see 3.5).
\uExamples:\n
    \utype\n VOLT \uis delta\n 0.125 \urange\n 0.0 .. 255.0;
    \usubtype\n ROUGH_VOLTAGE \uis\n VOLT \udelta\n 1.0;  --  same range as VOLT
    --  A pure fraction which requires all the available space in a word
    --  on a two's complement machine can be declared as the type FRACTION:
    DEL : \uconstant\n := 1.0/2**(WORD_LENGTH - 1);
    \utype\n FRACTION \uis delta\n DEL \urange\n -1.0 .. 1.0 - DEL;
3.5.10   \uOperations of Fixed Point Types\n
The \vbasic operations\v308. of a \vfixed point type\v319. include the \voperations\v305. involved
in  \vassignment\v502., \vmembership tests\v411., qualification, the explicit \vconversion\v419. of
values of other \vnumeric types\v310. to the fixed point  type,  and  the  implicit
conversion of values of the type \vuniversal_real\v316. to the type.
In  addition,  for every fixed point type or \vsubtype\v305. T the basic operations
include the attributes listed below.  In this presentation T is referred to
as being a subtype (the  subtype  T)  for  any  property  that  depends  on
constraints imposed by T;  other properties are stated in terms of the base
type of T.
The  first group of attributes yield characteristics of the subtype T.  The
attributes  of  this  group  are  the  attributes  BASE  (see  3.3.2),  the
attributes FIRST and LAST (see 3.5), the representation attribute SIZE (see
13.7.2) and the following attributes:
T'DELTA      Yields the value of the \vdelta\v319. specified in the fixed  accuracy
             definition  for the subtype T.  The value of this attribute is
             of the type universal_real.
T'MANTISSA   Yields the number of binary digits in the  mantissa  of  model
             numbers of the subtype T.  (This attribute yields the number B
             of section 3.5.9.)  The value of this attribute is of the type
             \vuniversal_integer\v314..
T'SMALL      Yields the smallest positive (nonzero)  \vmodel  number\v316.  of  the
             subtype  T.   The  value  of  this  attribute  is  of the type
             universal_real.
T'LARGE      Yields the largest positive model number  of  the  subtype  T.
             The value of this attribute is of the type universal_real.
T'FORE       Yields the minimum number of characters needed for the integer
             part of the decimal representation of any value of the subtype
             T,  assuming  that  the  representation  does  not  include an
             exponent, but includes a one-character prefix that is either a
             minus sign or a space.  (This minimum number does not  include
             superfluous  zeros  or  underlines, and is at least two.)  The
             value of this attribute is of the type universal_integer.
T'AFT        Yields the number of decimal digits needed after the point  to
             accommodate  the  precision of the subtype T, unless the delta
             of the subtype T is  greater  than  0.1,  in  which  case  the
             attribute  yields  the  value  one.   (T'AFT  is  the smallest
             positive integer N for which (10**N)*T'DELTA is  greater  than
             or  equal to one.)  The value of this attribute is of the type
             universal_integer.
The attributes of the second group include the following  attributes  which
yield characteristics of the \vsafe numbers\v316.:
T'SAFE_SMALL Yields the smallest positive (nonzero) safe number of the base
             type  of  T.   The  value  of  this  attribute  is of the type
             universal_real.
T'SAFE_LARGE Yields the largest positive safe number of the \vbase type\v305. of T.
             The value of this attribute is of the type universal_real.
In addition, the attributes A'SIZE and A'ADDRESS are defined for an  \vobject\v302.
A  of  a fixed point type (see 13.7.2).  Finally, for each fixed point type
or subtype T, there are the machine-dependent  attributes  T'MACHINE_ROUNDS
and T'MACHINE_OVERFLOWS (see 13.7.3).
Besides  the basic operations, the operations of a fixed point type include
the  \vrelational  operators\v411.,  and  the   following   predefined   \varithmetic\v315.
\voperators\v315.:   the binary and unary \vadding operators\v411. - and +, the \vmultiplying\v411.
operators * and /, and the operator \uabs\n.
The operations of a subtype are the corresponding operations  of  the  type
except  for  the  following:   assignment, membership tests, qualification,
explicit conversion, and the attributes of the first group;  the effects of
these operations are redefined in terms of the subtype.
\uNotes:\n
The value of the attribute T'FORE depends only on the range of the  subtype
T.   The value of the attribute T'AFT depends only on the value of T'DELTA.
The following relations exist between attributes of a fixed point type:
    T'LARGE      = (2**T'MANTISSA - 1) * T'SMALL
    T'SAFE_LARGE = T'BASE'LARGE
    T'SAFE_SMALL = T'BASE'SMALL
3.6      \uArray Types\n
An array object is a composite object consisting of  \vcomponents\v305.  that  have
the  same  subtype.   The \vname\v401. for a component of an array uses one or more
index values belonging to specified \vdiscrete types\v310..  The value of an  array
\vobject\v302. is a composite value consisting of the values of its components.
    array_type_definition ::=
       unconstrained_array_definition | constrained_array_definition
    unconstrained_array_definition ::=
       \uarray\n(index_subtype_definition {, index_subtype_definition}) \uof\n
                component_subtype_indication
    constrained_array_definition ::=
       \uarray\n index_constraint \uof\n component_subtype_indication
    index_subtype_definition ::= type_mark \urange\n <>
    index_constraint ::=  (discrete_range {, discrete_range})
    discrete_range ::= discrete_subtype_indication | \urange\n
An   array   object   is  characterized  by  the  number  of  indices  (the
dimensionality of the array), the type and  position  of  each  index,  the
lower and upper bounds for each index, and the type and possible \vconstraint\v305.
of the components.  The order of the indices is significant.
A  one-dimensional  array  has a distinct component for each possible index
value.  A multidimensional array has a distinct component for each possible
sequence of index values that can be formed by  selecting   one  value  for
each  index position (in the given order).  The possible values for a given
index are all the values between the lower  and  upper  bounds,  inclusive;
this \vrange\v305. of values is called the index range.
An  unconstrained  array definition defines an array type.  For each object
that has the array type, the number of indices, the type  and  position  of
each  index,  and  the  subtype  of  the  components  are  as  in  the type
definition;  the values of the lower and upper bounds for each index belong
to the corresponding index subtype, except for null arrays as explained  in
section  3.6.1.   The  index  subtype  for  a  given  index position is, by
definition, the subtype denoted by the \vtype mark\v307. of the corresponding index
subtype definition.  The compound delimiter <> (called a box) of  an  index
subtype  definition stands for an undefined range (different objects of the
type need not have the same bounds).  The \velaboration\v301. of  an  unconstrained
array  definition creates an array type;  this elaboration includes that of
the component subtype indication.
A constrained array definition defines both an array type and a subtype  of
this type:
  -  The array type is an implicitly declared \vanonymous type\v306.;  this type is
     defined  by an (implicit) unconstrained array definition, in which the
     component  subtype  indication  is  that  of  the  constrained   array
     definition,  and  in  which  the  type  mark  of  each  index  subtype
     definition denotes the subtype defined by the  corresponding  discrete
     range.
  -  The array subtype is the subtype obtained by imposition of  the  index
     constraint on the array type.
If  a  constrained  array  definition  is given for a \vtype declaration\v306., the
simple name declared by this declaration denotes the array subtype.
The elaboration of a constrained array definition creates the corresponding
array type and array subtype.  For this elaboration, the  index  constraint
and  the  component  subtype  indication are elaborated.  The evaluation of
each discrete range of the index constraint  and  the  elaboration  of  the
component  subtype  indication  are  performed  in  some  order that is not
defined by the language.
Examples of type declarations with unconstrained array definitions:
    \utype\n VECTOR     \uis array\n(INTEGER  \urange\n <>) \uof\n REAL;
    \utype\n MATRIX     \uis array\n(INTEGER  \urange\n <>, INTEGER \urange\n <>) \uof\n REAL;
    \utype\n BIT_VECTOR \uis array\n(INTEGER  \urange\n <>) \uof\n BOOLEAN;
    \utype\n ROMAN      \uis array\n(POSITIVE \urange\n <>) \uof\n ROMAN_DIGIT;
Examples of type declarations with constrained array definitions:
    \utype\n TABLE    \uis array\n(1 .. 10) \uof\n INTEGER;
    \utype\n SCHEDULE \uis array\n(DAY) \uof\n BOOLEAN;
    \utype\n LINE     \uis array\n(1 .. MAX_LINE_SIZE) \uof\n CHARACTER;
Examples of object declarations with constrained array definitions:
    GRID : \uarray\n(1 .. 80, 1 .. 100) \uof\n BOOLEAN;
    MIX  : \uarray\n(COLOR \urange\n RED .. GREEN) \uof\n BOOLEAN;
    PAGE : \uarray\n(1 .. 50) \uof\n LINE;  --  an array of arrays
Note:
For a one-dimensional array, the rule given means that a  type  declaration
with a constrained array definition such as
    \utype\n T \uis array\n(POSITIVE \urange\n MIN .. MAX) \uof\n COMPONENT;
is  equivalent  (in  the  absence  of an incorrect order dependence) to the
succession of declarations
    \usubtype\n index_subtype \uis\n POSITIVE \urange\n MIN .. MAX;
    \utype\n array_type \uis\n \uarray\n(index_subtype range <>) \uof\n COMPONENT;
    \usubtype\n T \uis\n array_type (index_subtype);
where index_subtype and array_type are both anonymous.  Consequently, T  is
the  name  of  a  subtype  and all objects declared with this type mark are
arrays that  have  the  same  bounds.   Similar  transformations  apply  to
multidimensional arrays.
A  similar transformation applies to an object whose declaration includes a
constrained array definition.  A consequence of this is that  no  two  such
objects have the same type.
More details:
 3.6.1  \vIndex Constraints and Discrete Ranges\v322.
 3.6.2  \vOperations of Array Types\v323.
 3.6.3  \vThe Type String\v324.
3.6.1    \uIndex Constraints and Discrete Ranges\n
An \vindex constraint\v322. determines the \vrange\v310. of possible values for every \vindex\v321.
of an \varray type\v321., and thereby the corresponding \varray bounds\v321..
For a \vdiscrete range\v321. used in a constrained \varray definition\v321. and defined  by
a  range,  an implicit \vconversion\v419. to the predefined type INTEGER is assumed
if each bound is either a numeric literal, a named number, or an attribute,
and the type of both bounds (prior to the implicit conversion) is the  type
universal_integer.   Otherwise,  both  bounds  must be of the same discrete
type,  other  than  \vuniversal_integer\v314.;   this  type  must  be  determinable
independently  of  the  context,  but  using the fact that the type must be
discrete and that both bounds must have the same type.  These  rules  apply
also  to  a  discrete  range  used in an \viteration rule\v506. (see 5.5) or in the
declaration of a family of entries (see 9.5).
If an index constraint follows a \vtype mark\v307. in a  \vsubtype  indication\v307.,  then
the  type  or  subtype  denoted by the type mark must not already impose an
index constraint.  The type mark must denote either an \vunconstrained  array\v321.
type  or  an  \vaccess  type\v330. whose \vdesignated\v330. type is such an array type.  In
either case, the index constraint must provide a discrete  range  for  each
index  of  the  array  type and the type of each discrete range must be the
same as that of the corresponding index.
An index constraint is \vcompatible\v307. with the type denoted by the type mark if
and only if the constraint defined by each  discrete  range  is  compatible
with  the  corresponding  \vindex  subtype\v321..   If  any  of the discrete ranges
defines a \vnull range\v310., any array thus constrained is a null array, having no
components.  An array value satisfies an index constraint if at each  index
position  the  array  value  and  the  index constraint have the same index
bounds.  (Note,  however, that assignment and certain other  operations  on
arrays involve an implicit \vsubtype conversion\v419..)
The bounds of each array \vobject\v302. are determined as follows:
  -  For  a  \vvariable\v303.  declared  by  an  \vobject  declaration\v303.,  the  subtype
     indication  of  the  corresponding  object  declaration  must define a
     \vconstrained array  subtype\v321.  (and,  thereby,  the  bounds).   The  same
     requirement   exists   for  the  subtype  indication  of  a  \vcomponent\v325.
     \vdeclaration\v325., if the type of the \vrecord component\v325.  is  an  array  type;
     and  for the component subtype indication of an array type definition,
     if the type of the array components is itself an array type.
  -  For a \vconstant\v303. declared by an object declaration, the  bounds  of  the
     constant  are  defined  by  the  \vinitial  value\v303.  if the subtype of the
     constant is unconstrained;  they are otherwise defined by this subtype
     (in the latter case, the initial value is the result  of  an  implicit
     subtype  conversion).   The  same  rule  applies  to  a \vgeneric formal\v1201.
     parameter of \vmode\v1202. in.
  -  For an array object designated by an \vaccess value\v330., the bounds must  be
     defined  by  the  \vallocator\v421.  that  creates  the  array  object.   (The
     allocated object is constrained with the corresponding values  of  the
     bounds.)
  -  For a \vformal parameter\v601. of  a  \vsubprogram\v600.  or  \ventry\v905.,  the  bounds  are
     obtained   from  the  corresponding  \vactual  parameter\v607..   (The  formal
     parameter is constrained with the corresponding values of the bounds.)
  -  For a \vrenaming declaration\v805. and for a generic \vformal parameter\v601. of  mode
     in  out,  the  bounds  are  those  of  the  renamed  object  or of the
     corresponding \vgeneric actual parameter\v1206..
For the elaboration  of  an  index  constraint,  the  discrete  ranges  are
evaluated in some order that is not defined by the language.
Examples of array declarations including an index constraint:
    BOARD     : MATRIX(1 .. 8,  1 .. 8);  --  see 3.6
    RECTANGLE : MATRIX(1 .. 20, 1 .. 30);
    INVERSE   : MATRIX(1 .. N,  1 .. N);  --  N need not be static
    FILTER    : BIT_VECTOR(0 .. 31);
Example of array declaration with a constrained array subtype:
    MY_SCHEDULE : SCHEDULE;  --  all arrays of type SCHEDULE have the same
                                 bounds
Example of record type with a component that is an array:
    \utype\n VAR_LINE(LENGTH : INTEGER) \uis\n
       \urecord\n
          IMAGE : STRING(1 .. LENGTH);
       \uend record\n;
    NULL_LINE : VAR_LINE(0);  --  NULL_LINE.IMAGE is a null array
\uNotes:\n
The  elaboration of a subtype indication consisting of a type mark followed
by an index constraint checks the compatibility  of  the  index  constraint
with the type mark (see 3.3.2).
All  components  of  an array have the same subtype.  In particular, for an
array of components that are one-dimensional arrays, this  means  that  all
components have the same  bounds and hence the same length.
3.6.2    \uOperations of Array Types\n
The \vbasic operations\v308. of an array type include the  operations  involved  in
\vassignment\v502.  and  \vaggregates\v407.  (unless the \varray type\v321. is limited), \vmembership\v411.
\vtests\v411., \vindexed components\v402., qualification,  and  explicit  \vconversion\v419.;   for
one-dimensional  arrays  the  basic  operations also include the operations
involved in \vslices\v403., and also \vstring literals\v208. if the  component  type  is  a
\vcharacter type\v312..
If  A  is  an array \vobject\v302., an array value, or a \vconstrained array subtype\v321.,
the basic operations also  include  the  \vattributes\v405.  listed  below.   These
attributes are not allowed for an \vunconstrained array type\v321..  The argument N
used  in  the attribute \vdesignators\v601. for the N-th \vdimension\v321. of an array must
be a \vstatic expression\v422. of type universal_integer.  The value of N  must  be
positive (nonzero) and no greater than the dimensionality of the array.
A'FIRST         Yields the lower bound of the first \vindex\v321. range.  The value
                of this attribute has the same type as this lower bound.
A'FIRST(N)      Yields the lower bound of the N-th index range.  The  value
                of this attribute has the same type as this lower bound.
A'LAST          Yields the upper bound of the first index range.  The value
                of this attribute has the same type as this upper bound.
A'LAST(N)       Yields the upper bound of the N-th index range.  The  value
                of this attribute has the same type as this upper bound.
A'RANGE         Yields the first index range, that is, the range A'FIRST ..
                A'LAST.
A'RANGE(N)      Yields the N-th index range, that is, the range  A'FIRST(N)
                .. A'LAST(N).
A'LENGTH        Yields the number of values of the first index range  (zero
                for  a  \vnull range\v310.).  The value of this attribute is of the
                type universal_integer.
A'LENGTH(N)     Yields the number of values of the N-th index  range  (zero
                for  a  null range).  The value of this attribute is of the
                \vtype universal_integer\v314..
In addition, the attribute T'BASE is defined for an array type or subtype T
(see 3.3.3);  the attribute T'SIZE is defined for an array type or  subtype
T,  and the attributes A'SIZE and A'ADDRESS are defined for an array object
A (see 13.7.2).
Besides the basic operations, the operations of an array type  include  the
predefined comparison for equality and inequality, unless the array type is
limited.   For  one-dimensional  arrays, the operations include \vcatenation\v411.,
unless the array \vtype is limited\v708.;  if the  component  type  is  a  discrete
type,  the operations also include all predefined \vrelational operators\v411.;  if
the component type is a boolean type, then the operations also include  the
unary logical negation \voperator not\v411., and the \vlogical operators\v411..
Examples (using arrays declared in the examples of section 3.6.1):
--  FILTER'FIRST      =   0   FILTER'LAST       = 31   FILTER'LENGTH  =  32
--  RECTANGLE'LAST(1) =   20  RECTANGLE'LAST(2) = 30
\uNotes:\n
The  attributes  A'FIRST  and  A'FIRST(1)  yield the same value.  A similar
relation exists for the attributes  A'LAST,  A'RANGE,  and  A'LENGTH.   The
following  relations  are  satisfied (except for a null array) by the above
attributes if the index type is an integer type:
    A'LENGTH    = A'LAST    - A'FIRST    + 1
    A'LENGTH(N) = A'LAST(N) - A'FIRST(N) + 1
An array type is limited if its component type is limited (see 7.4.4).
3.6.3    \uThe Type String\n
The  values of the predefined type STRING are one-dimensional arrays of the
predefined \vtype CHARACTER\v312., indexed by  values  of  the  predefined  subtype
POSITIVE:
    \usubtype\n POSITIVE \uis\n INTEGER \urange\n 1 .. INTEGER'LAST;
    \utype\n STRING \uis array\n(POSITIVE \urange\n <>) \uof\n CHARACTER;
\uExamples:\n
    STARS      : STRING(1 .. 120) := (1 .. 120 => '*' );
    QUESTION   : \uconstant\n STRING  := "HOW MANY CHARACTERS?";
    --  QUESTION'FIRST = 1, QUESTION'LAST = 20 (the number of characters)
    ASK_TWICE  : \uconstant\n STRING  := QUESTION & QUESTION;
    NINETY_SIX : \uconstant\n WOMAN   := "XCVI";        --  see 3.6
\uNotes:\n
String  literals  (see  2.6 and 4.2) are basic operations applicable to the
\vtype\v321. STRING and to any other one-dimensional  array  type  whose  \vcomponent\v321.
type is a character type.  The \vcatenation operator\v411. is a \vpredefined\v411. \voperator\v411.
for the type STRING and for one-dimensional array types;  it is represented
as  &.  The relational operators <, <=, >, and >= are defined for values of
these types, and correspond to \vlexicographic order\v413. (see 4.5.2).
3.7      \uRecord Types\n
A record \vobject\v302. is a composite object consisting of named \vcomponents\v305..   The
value  of  a record object is a \vcomposite value\v305. consisting of the values of
its components.
    record_type_definition ::=
       \urecord\n
          component_list
       \uend record\n
    component_list ::=
          component_declaration {component_declaration}
       | {component_declaration} \vvariant_part\v328.
       |  \unull\n;
    component_declaration ::=
       \videntifier_list\v302. : component_subtype_definition [:= expression];
    component_subtype_definition ::=  subtype_indication
Each component  \vdeclaration\v301.  declares  a  component  of  the  record  type.
Besides  components declared by component declarations, the components of a
record type include any components declared by \vdiscriminant\v305.  specifications
of  the  record  type  declaration.  The identifiers of all components of a
record type must be distinct.  The use of a  \vname\v401.  that  denotes  a  record
component  other  than a discriminant is not allowed within the record type
definition that declares the component.
A component  declaration  with  several  identifiers  is  equivalent  to  a
sequence  of  single  component  declarations, as explained in section 3.2.
Each single component declaration declares a record component whose subtype
is specified by the component subtype definition.
If a component  declaration  includes  the  \vassignment  compound  delimiter\v202.
followed  by an \vexpression\v410., the expression is the default expression of the
record component;  the default expression  must  be  of  the  type  of  the
component.   Default expressions are not allowed for components that are of
a \vlimited type\v708..
If a record type does not have a \vdiscriminant part\v325., the same components are
present in all values of the type.  If the component list of a record  type
is  defined  by  the  reserved word null and there is no discriminant part,
then the record type has no components and all records of the type are null
records.
The \velaboration\v333. of a record type definition  creates  a  record  type;   it
consists  of  the  elaboration  of  any  corresponding  (single)  component
declarations, in the order in which they appear,  including  any  component
declaration  in a variant part.  The elaboration of a component declaration
consists of the elaboration of the component subtype definition.
For the elaboration of a component subtype definition,  if  the  \vconstraint\v305.
does  not \vdepend on a discriminant\v326. (see 3.7.1), then the subtype indication
is elaborated.  If,  on  the  other  hand,  the  constraint  depends  on  a
discriminant,  then  the  elaboration  consists  of  the  evaluation of any
included expression that is not a discriminant.
Examples of record type declarations:
    \utype\n DATE \uis\n
       \urecord\n
          DAY   : INTEGER \urange\n 1 .. 31;
          MONTH : MONTH_NAME;
          YEAR  : INTEGER \urange\n 0 .. 4000;
       \uend record\n;
    \utype\n COMPLEX \uis\n
       \urecord\n
          RE : REAL := 0.0;
          IM : REAL := 0.0;
       \uend record\n;
Examples of record variables:
    TOMORROW, YESTERDAY : DATE;
    A, B, C : COMPLEX;
    -- both components of A, B, and C are implicitly initialized to zero
\uNotes:\n
The default expression of a record component is implicitly evaluated by the
elaboration of the declaration of a record object, in  the  absence  of  an
explicit  initialization  (see  3.2.1).   If  a  component  declaration has
several identifiers,  the  expression  is  evaluated  once  for  each  such
component  of the object (since the declaration is equivalent to a sequence
of single component declarations).
Unlike the components of an array, the components of a record need  not  be
of the same type.
More details:
 3.7.1  \vDiscriminants\v326.
 3.7.2  \vDiscriminant Constraints\v327.
 3.7.3  \vVariant Parts\v328.
 3.7.4  \vOperations of Record Types\v329.
3.7.1    \uDiscriminants\n
A discriminant part specifies the discriminants of a type.  A  discriminant
of  a record is a \vcomponent of the record\v325..  The type of a discriminant must
be discrete.
    discriminant_part ::=
       (discriminant_specification {; discriminant_specification})
    discriminant_specification ::=
       identifier_list : type_mark [:= expression]
A discriminant part is only allowed in the type \vdeclaration\v301.  for  a  record
type,  in a \vprivate type\v704. declaration or an \vincomplete type\v331. \vdeclaration\v331. (the
corresponding full declaration must then declare a \vrecord type\v325.), and in the
\vgeneric parameter declaration\v1201. for a formal private type.
A discriminant specification with several \videntifiers\v203. is  equivalent  to  a
sequence  of  single  discriminant  specifications, as explained in section
3.2.  Each single discriminant specification declares a discriminant.  If a
discriminant  specification  includes  the  \vassignment  compound  delimiter\v202.
followed  by an expression, the expression is the default expression of the
discriminant;   the  default  expression  must  be  of  the  type  of   the
discriminant.   Default  expressions must be provided either for all or for
none of the discriminants of a discriminant part.
The use of the name of a discriminant is not allowed in default expressions
of a discriminant part if the specification of the discriminant  is  itself
given in the discriminant part.
Within  a  record  type  definition  the only allowed uses of the name of a
discriminant of the record type are:  in the default expressions for record
components;  in a  variant  part  as  the  discriminant  name;   and  in  a
component  subtype definition, either as a bound in an \vindex constraint\v322., or
to  specify  a  discriminant  value  in  a  discriminant   constraint.    A
discriminant  name  used in these component subtype definitions must appear
by itself, not as part of a  larger  expression.   Such  component  subtype
definitions and such constraints are said to depend on a discriminant.
A component is said to depend on a discriminant if it is a record component
declared  in  a variant part, or a record component whose component subtype
definition depends on a discriminant, or finally, one of the  \vsubcomponents\v305.
of a component that itself depends on a discriminant.
Each  record value includes a value for each discriminant specified for the
record type;  it also includes a value for each record component that  does
not  depend  on  a discriminant.  The values of the discriminants determine
which other component values are in the record value.
Direct  \vassignment\v502.  to  a  discriminant  of  an  object  is  not   allowed;
furthermore a discriminant is not allowed as an actual parameter of mode in
out  or  out,  or  as  a generic actual parameter of mode in out.  The only
allowed way to change the value of a  discriminant  of  a  variable  is  to
assign a (complete) value to the variable itself.  Similarly, an assignment
to  the variable itself is the only allowed way to change the constraint of
one of its components, if the component subtype  definition  depends  on  a
discriminant of the variable.
The elaboration of a discriminant part has no other effect.
\uExamples:\n
    \utype\n BUFFER(SIZE : BUFFER_SIZE := 100)  \uis\n        -- see 3.5.4
       \urecord\n
          POS   : BUFFER_SIZE := 0;
          VALUE : STRING(1 .. SIZE);
       \uend record\n;
    \utype\n SQUARE(SIDE : INTEGER) \uis\n
       \urecord\n
          MAT : MATRIX(1 .. SIDE, 1 .. SIDE);       -- see 3.6
       \uend record\n;
    \utype\n DOUBLE_SQUARE(NUMBER : INTEGER) \uis\n
       \urecord\n
          LEFT  : SQUARE(NUMBER);
          RIGHT : SQUARE(NUMBER);
       \uend record\n;
    \utype\n ITEM(NUMBER : POSITIVE) \uis\n
       \urecord\n
          CONTENT : INTEGER;
          --  no component depends on the discriminant
       \uend record\n;
3.7.2    \uDiscriminant Constraints\n
A  discriminant constraint is only allowed in a \vsubtype\v305. indication, after a
type mark.  This type mark must denote either a type with discriminants, or
an \vaccess type\v330. whose \vdesignated type\v330.  is  a  type  with  \vdiscriminants\v305..   A
discriminant constraint specifies the values of these discriminants.
    discriminant_constraint ::=
      (discriminant_association {, discriminant_association})
    discriminant_association ::=
      [discriminant_simple_name {| discriminant_simple_name} =>] expression
Each  discriminant  association  associates  an \vexpression\v410. with one or more
discriminants.  A discriminant association is  said  to  be  named  if  the
discriminants  are  specified  explicitly  by their \vnames\v401.;  it is otherwise
said  to  be  positional.   For  a  positional  association,  the  (single)
discriminant  is implicitly specified by position, in textual order.  Named
associations can be given in any order, but if both  positional  and  named
associations  are used in the same discriminant constraint, then positional
associations must occur first, at their  normal  position.   Hence  once  a
named association is used, the rest of the discriminant constraint must use
only named associations.
For  a  named  discriminant association, the discriminant names must denote
discriminants of the type for which the discriminant constraint  is  given.
A  discriminant  association  with  more than one discriminant name is only
allowed if the named discriminants are all of the same type.   Furthermore,
for  each  discriminant  association  (whether  named  or  positional), the
expression and the associated discriminants must have  the  same  type.   A
discriminant   constraint   must   provide   exactly  one  value  for  each
discriminant of the type.
A discriminant constraint is \vcompatible\v307. with the type  denoted  by  a  type
mark,  if and only if each discriminant value belongs to the subtype of the
corresponding discriminant.   In  addition,  for  each  \vsubcomponent\v305.  whose
\vcomponent   subtype   specification\v325.   \vdepends   on    a \v326. \vdiscriminant\v326.,  the
discriminant value is substituted for the discriminant  in  this  component
subtype  specification  and  the  compatibility  of  the  resulting subtype
indication is checked.
A \vcomposite value\v305. satisfies a discriminant constraint if and only  if  each
discriminant   of  the  composite  value  has  the  value  imposed  by  the
discriminant constraint.
The initial values of the  discriminants  of  an  \vobject\v302.  of  a  type  with
discriminants are determined as follows:
  -  For  a  \vvariable\v303.  declared  by  an  object  declaration,  the  subtype
     indication  of  the  corresponding  object  declaration  must impose a
     discriminant constraint  unless  \vdefault  expressions\v325.  exist  for  the
     discriminants;   the  discriminant  values  are  defined either by the
     constraint or, in its absence, by the default expressions.   The  same
     requirement   exists   for  the  subtype  indication  of  a  \vcomponent\v325.
     \vdeclaration\v325., if the type of the record  component  has  discriminants;
     and for the component subtype indication of an \varray type\v321., if the type
     of the array components is a type with discriminants.
  -  For a constant declared by an object declaration, the  values  of  the
     discriminants  are  those  of  the initial value if the subtype of the
     constant is unconstrained;  they are otherwise defined by this subtype
     (in the latter case, an exception is raised if the initial value  does
     not  belong  to  this  subtype).   The  same rule applies to a generic
     parameter of \vmode in\v601..
  -  For an object designated by an access value, the  discriminant  values
     must  be  defined  by  the  \vallocator\v421.  that  creates the object.  (The
     allocated object is constrained with  the  corresponding  discriminant
     values.)
  -  For a \vformal parameter\v601. of a \vsubprogram\v600. or \ventry\v905., the discriminants  of
     the  formal  parameter are initialized with those of the corresponding
     \vactual  parameter\v607..   (The  formal  parameter  is  constrained  if  the
     corresponding  actual parameter is constrained, and in any case if the
     mode is in or if the subtype of the formal parameter is  constrained.)
  -  For a \vrenaming declaration\v805. and for a \vgeneric formal parameter\v1201. of  mode
     in  out,  the  discriminants are those of the renamed object or of the
     corresponding \vgeneric actual parameter\v1206..
For the \velaboration\v333. of a discriminant constraint, the expressions given  in
the  discriminant  associations  are  evaluated  in  some order that is not
defined by  the  language;   the  expression  of  a  named  association  is
evaluated once for each named discriminant.
Examples (using types declared in the previous section): 01
  LARGE   : BUFFER(200);  --  constrained, always 200 characters (explicit
                              discriminant value)
  MESSAGE : BUFFER;       --  unconstrained, initially 100 characters
                              (default discriminant value)
  BASIS   : SQUARE(5);    --  constrained, always 5 by 5
  ILLEGAL : SQUARE;       --  illegal, a SQUARE must be constrained
Note:
The  above  rules  and  the  rules  defining  the  elaboration of an object
declaration (see 3.2) ensure that discriminants always have  a  value.   In
particular,   if   a  discriminant  constraint  is  imposed  on  an  object
declaration, each discriminant is initialized with the value  specified  by
the   constraint.    Similarly,  if  the  subtype  of  a  component  has  a
discriminant  constraint,  the   discriminants   of   the   component   are
correspondingly initialized.
3.7.3    \uVariant Parts\n
A   \vrecord  type\v325.  with  a  variant  part  specifies  alternative  lists  of
\vcomponents\v305..  Each variant defines  the  components  for  the  corresponding
value or values of the discriminant.
    variant_part ::=
       \ucase\n discriminant_simple_name \uis\n
           variant
          {variant}
       \uend case\n;
    variant ::=
       \uwhen\n choice {| choice} =>
          \vcomponent_list\v325.
    choice ::= \vsimple_expression\v410.
       | \vdiscrete_range\v321. | \uothers\n | component_simple_name
Each  variant  starts with a list of choices which must be of the same type
as the \vdiscriminant\v305. of the variant part.  The type of the discriminant of a
variant part must not be a \vgeneric formal type\v1201..   If  the  \vsubtype\v305.  of  the
discriminant is static, then each value of this subtype must be represented
once  and only once in the set of choices of the variant part, and no other
value is allowed.   Otherwise,  each  value  of  the  \v(base)  type\v305.  of  the
discriminant  must be represented once and only once in the set of choices.
The simple expressions and discrete \vranges\v310. given as choices  in  a  variant
part  must  be static.  A choice defined by a discrete range stands for all
values in the corresponding range (none  if  a  \vnull  range\v310.).   The  choice
others  is  only  allowed  for the last variant and as its only choice;  it
stands for all values (possibly none) not given in the choices of  previous
variants.   A component \vsimple name\v401. is not allowed as a choice of a variant
(although it is part of the syntax of choice).
A record value contains the values of the components of a given variant  if
and  only if the discriminant value is equal to one of the values specified
by the choices of the variant.  This rule applies in turn  to  any  further
variant  that  is,  itself,  included  in  the  component list of the given
variant.  If the component list of a variant  is  specified  by  null,  the
variant has no components.
Example of record type with a variant part:
    \utype\n DEVICE \uis\n (PRINTER, DISK, DRUM);
    \utype\n STATE  \uis\n (OPEN, CLOSED);
    \utype\n PERIPHERAL(UNIT : DEVICE := DISK) \uis\n
       \urecord\n
          STATUS : STATE;
          \ucase\n UNIT \uis\n
             \uwhen\n PRINTER =>
                LINE_COUNT : INTEGER \urange\n 1 .. PAGE_SIZE;
             \uwhen others\n =>
                CYLINDER   : CYLINDER_INDEX;
                TRACK      : TRACK_NUMBER;
             \uend case\n;
          \uend record\n;
Examples of record subtypes:
    \usubtype\n DRUM_UNIT \uis\n PERIPHERAL(DRUM);
    \usubtype\n DISK_UNIT \uis\n PERIPHERAL(DISK);
Examples of constrained record ariables:
    WRITER   : PERIPHERAL(UNIT  => PRINTER);
    ARCHIVE  : DISK_UNIT;
Note:
Choices with discrete values are also used in case statements and in  \varray\v409.
\vaggregates\v409..   Choices  with  component  simple  names  are  used  in record
aggregates.
3.7.4    \uOperations of Record Types\n
The \vbasic operations\v308. of a \vrecord type\v325. include the  operations  involved  in
\vassignment\v502. and aggregates (unless the type is limited),  membership  tests,
selection of record components, qualifications, and  type  \vconversion\v419.  (for
\vderived types\v309.)
For any \vobject\v303. A of a type with \vdiscriminants\v305., the  basic  \voperations\v305.  also
include the following \vattribute\v405.:
A'CONSTRAINED     Yields the value  TRUE  if  the  discriminant  constraint
                  applies to the object A, or if the object is  a  \vconstant\v303.
                  (including a formal parameter or generic formal parameter
                  of \vmode\v303. in); yields the value FALSE otherwise.  If A is a
                  generic  formal  parameter  of  mode in out, or if A is a
                  formal parameter of mode in out or out and the type  mark
                  given  in  the  corresponding   parameter   specification
                  denotes  an  unconstrained  type with discriminants, then
                  the value of this attribute is obtained from that of  the
                  corresponding \vactual parameter\v607..  The value of this attri-
                  bute is of the predefined type \vBOOLEAN\v313..
In addition, the attributes T'BASE and T'SIZE are defined for a record type
or subtype T (see 3.3.3); the attributes A'SIZE and  A'ADDRESS  are defined
for a record object A (see 13.7.2).
Besides  the  basic operations, the operations of a record type include the
predefined  comparison  for  equality  and  inequality,  unless the type is
limited.
Note:
A record type is limited if the type of any of its  components  is  limited
(see 7.4.2).
3.8      \uAcess Types\n
An object declared by an object declaration is created by  the  \velaboration\v333.
of the object declaration and is denoted by a simple \vname\v401. or by some  other
form of name.  In contrast, there are objects that are created by the eval-
uation of \vallocators\v421. (see 4.8) and that have no  simple  name.   Access  to
such an object is achieved by an access value returned by an allocator; the
access value is said to designate the object.
    access_type_definition ::= \uaccess\n subtype_indication
For each access type, there is a \vliteral\v406. null which has a null access value
designating  no  object  at  all.   The null value of an access type is the
default initial value of the type.  Other values  of  an  access  type  are
obtained  by  evaluation  of  a  special  operation  of  the type called an
allocator.  Each such access value designates  an  object  of  the  \vsubtype\v305.
defined  by  the  \vsubtype  indication\v307.  of  the access type definition; this
subtype is called the designated subtype;  the base type of this subtype is
called  the  designated  type.   The objects designated by the values of an
access type form a collection implicitly associated with the type.
The elaboration of an access type definition consists of the elaboration of
the subtype indication and creates an access type.
If an access object is \vconstant\v303., the  constrained  access  value  cannot be
changed and always designates the same object. On the other hand, the value
of  the  designated  object  need  not  remain the same (\vassignment\v502.  to the
designated object is allowed unless the designated \vtype is limited\v708.).
The only forms of contraint that are allowed after the  name  of  an access
type  in  a  subtype  indication  are  index  \vconstraints\v305.  and \vdiscriminant\v327.
\vconstraints\v327..  (See  sections  3.6.1  and  3.7.2 for the rules applicable to
these subtype indications.)   An  access  value  belongs to a corresponding
subtype of an access type either if the access value  is  the null value or
if the value of the designated object satisfies the constraint.
\uExamples:\n
    \utype\n FRAME \uis access\n MATRIX;         --  see 3.6
    \utype\n BUFFER_NAME \uis access\n BUFFER    --  see 3.7.1
\uNotes:\n
An access value delivered by an allocator can be assigned to several access
objects.  Hence it is  possible for an object created by an allocator to be
designated by more than one  \vvariable\v303.  or  constant of the access type.  An
access  value  can only designate an object created  by  an  allocator;  in
particular,  it  cannot  designate  an  object  declared   by   an   object
declaration.
If the type of the objects designated by the access values is an \varray type\v321.
or a type with discriminants, these objects are constrained with either the
array  bounds  or  the discriminant values supplied implicitly or explicity
for the corresponding allocators (see 4.8).
Access values are called pointers of references in some other languages.
More details:
 3.8.1  \vIncomplete Type Declarations\v331.
 3.8.2  \vOperations of Access Types\v332.
3.8.1    \uIncomplete Type Declarations\n
There are  no particular limitations on  the  \vdesignated\v330.  type of an access
type.  In particular, the type of a \vcomponent\v305. of the designated type can be
another  \vaccess  type\v330., or even the same access type.  This permits mutually
dependent  and recursive access types.  Their declarations require a  prior
incomplete (or private) type declaration for one or more types.
     incomplete_type_declaration ::= type identifier [discriminant_part];
For  each incomplete  type  declaration,  there  must  be  a  corresponding
declaration  of  a  type  with  the  same  identifier.   The  corresponding
declaration must be either a full type declaration or the declarations of a
task type.  In the rest of this section, explanations are given in terms of
full  type declarations;  the same rules apply also to declarations of task
types.  If the incomplete type declaration occurs immediately within either
a declarative part or the visible part of a package specification, then the
full  type  declaration  must  occur  later  and  immediately  within  this
declarative part or visible part. If the incomplete type declaration occurs
immediately  within  private  part  of  a  package,  then  the  full   type
declaration must occur later and immediately within either the private part
itself, or the declarative part of the corresponding package body.
A \vdiscriminant part\v326. must be given in the full type  declaration if and only
if one is given in the incomplete type declaration;  if discriminant  parts
are given, then they must \vconform\v604. (see  6.3.1  for the  conformance rules).
Prior to the end of  the  full  type declaration, the only allowed use of a
\vname\v401. that  denotes  a type declared by an incomplete type declaration is as
the  \vtype  mark\v307. in the subtype indication of an \vaccess type definition\v330.; the
only  form  of  \vconstraint\v305.  allowed  in  this  subtype   indication  is   a
\vdiscriminant constraint\v327..
The \velaboration\v333.  of an  incomplete type \vdeclaration\v301. creates a type.  If the
incomplete type declaration  has  a  discriminant  part,  this  elaboration
includes  that of  the discriminant part:  in such a case, the discriminant
part of the full type declaration is not elaborated.
Example of a recursive type:
    \utype\n CELL;  --  incomplete type declaration
    \utype\n LINK \uis access\n CELL;
    \utype\n CELL \uis\n
       \urecord\n
          VALUE  : INTEGER;
          SUCC   : LINK;
          PRED   : LINK;
       \uend record\n;
    HEAD   : LINK  := \unew\n CELL'(O, \unull\n, \unull\n);
    NEXT   : LINK  := HEAD.SUCC;
Examples of mutually dependent access types:
    \utype\n PERSON(SEX : GENDER);  -- incomplete type declaration
    \utype\n CAR;                   -- incomplete type declaration
    \utype\n PERSON_NAME \uis access\n PERSON;
    \utype\n CAR_NAME    \uis access\n CAR;
    \utype\n CAR \uis\n
       \urecord\n
          NUMBER  : INTEGER;
          OWNER   :PERSON_NAME;
       \uend record\n;
    \utype\n PERSON(SEX : GENDER) \uis\n
       \urecord\n
          NAME     : STRING(1 .. 20);
          BIRTH    : DATE;
          AGE      : INTEGER \urange\n 0 .. 130;
          VEHICLE  : CAR_NAME;
          \ucase\n SEX \uis\n
             \uwhen\n M => WIFE           : PERSON_NAME(SEX => F);
             \uwhen\n F => HUSBAND        : PERSON_NAME(SEX => M);
          \uend case\n;
       \uend record\n;
    MY_CAR, YOUR_CAR, NEXT_CAR : CAR_NAME; -- implicitly initialized with
                                              null value
3.8.2    \uOperations of Access Types\n
The  basic  \voperations\v305. of an \vaccess type\v330. include the operations involved in
\vassignment\v502.,   \vallocators\v421.   for   the   access   type,   membership   tests,
qualification,   explicit   \vconversion\v419.,  and  the  \vliteral\v406.  null.   If  the
\vdesignated type\v330. is a type with \vdiscriminants\v305., the basic operations  include
the  selection  of the corresponding discriminants;  if the designated type
is  a  \vrecord  type\v325.,  they  include  the  selection  of  the  corresponding
components;   if  the  designated  type  is an \varray type\v321., they include the
formation of \vindexed components\v402. and slices;  if the designated  type  is  a
\vtask   type\v901.,   they  include  selection  of  entries  and  entry  families.
Furthermore, the basic operations  include  the  formation  of  a  \vselected\v404.
\vcomponent\v404. with the \vreserved word\v404. all (see 4.1.3).
If  the  designated type is an array type, the basic operations include the
\vattributes\v405. that have the \vattribute  designators\v405.  FIRST,  LAST,  RANGE,  and
LENGTH  (likewise,  the  attribute designators of the N-th dimension).  The
prefix of each of these attributes must be a  value  of  the  access  type.
These  attributes yield the corresponding characteristics of the designated
\vobject\v303. (see 3.6.2).
If the designated type is a task type, the  \vbasic  operations\v308.  include  the
attributes that have the attribute designators TERMINATED and CALLABLE (see
9.9).  The prefix of each of these attributes must be a value of the access
type.   These  attributes  yield  the  corresponding characteristics of the
designated task objects.
In addition, the  attribute  T'BASE  (see  3.3.3)  and  the  representation
attributes T'SIZE and T'STORAGE_SIZE (see 13.7.2) are defined for an access
type  or subtype T;  the attributes A'SIZE and A'ADDRESS are defined for an
access object A (see 13.7.2).
Besides the basic operations, the operations of an access type include  the
predefined comparison for equality and inequality.
3.9  \uDeclarative Parts\n
A declarative part contains declarative items (possibly none).
    declarative_part ::=
       {basic_declarative_item} {later_declarative_item}
    basic_declarative_item ::= basic_declaration
       | representation_clause | use_clause
    later_declarative_item ::= \ubody\n
       | subprogram_declaration | package_declaration
       | task_declaration       | generic_declaration
       | use_clause             | generic_instantiation
    \ubody\n ::= proper_body | body_stub
    proper_body ::= subprogram_body | package_body | task_body
The  elaboration  of  a declarative part consists of the elaboration of the
declarative items, if any, in the order in which  they  are  given  in  the
declarative  part.  After its elaboration, a declarative item is said to be
elaborated.  Prior to the completion of its elaboration  (including  before
the elaboration), the declarative item is not yet elaborated.
For  several  forms  of declarative item, the language rules (in particular
\vscope\v802. and \vvisibility\v803. rules) are  such  that  it  is  either  impossible  or
illegal  to  use  an  entity before the elaboration of the declarative item
that declares this entity.  For example, it is not possible to use the name
of a \vtype\v305. for an object declaration if the corresponding  type  declaration
is  not  yet  elaborated.   In the case of bodies, the following checks are
performed:
  -  For a \vsubprogram call\v606., a check is made that the body of the subprogram
     is already elaborated.
  -  For the \vactivation\v903. of a task, a check is made that  the  body  of  the
     corresponding task unit is already elaborated.
  -  For the \vinstantiation\v1206. of a generic unit that has a body,  a  check  is
     made that this body is already elaborated.
The exception \vPROGRAM_ERROR\v1101. is raised if any of these checks fails.
If  a subprogram declaration, a package declaration, a task declaration, or
a generic declaration is a declarative item of a  given  declarative  part,
then  the  body  (if  there  is  one)  of  the program unit declared by the
declarative item must itself be a declarative item of this declarative part
(and must appear later).  If the body is a body  stub,  then  a  separately
compiled  subunit  containing the corresponding proper body is required for
the program unit (see 10.2).
4.      \u Names and Expressions\n
The rules applicable to the different forms of name and expression, and  to
their evaluation, are given in this chapter.
More details:
 4.1    \vNames\v401.
 4.2    \vLiterals\v406.
 4.3    \vAggregates\v407.
 4.4    \vExpressions\v410.
 4.5    \vOperators and Expression Evaluation\v411.
 4.6    \vType Conversions\v419.
 4.7    \vQualified Expressions\v420.
 4.8    \vAllocators\v421.
 4.9    \vStatic Expressions  and Static Subtypes\v422.
 4.10   \vUniversal Expression\v423.
4.1  \uNames\n
Names   can  denote  declared  entities,  whether  declared  explicitly  or
implicitly (see 3.1).  Names can also denote objects \vdesignated\v330.  by  access
values;   subcomponents  and \vslices\v403. of objects and values;  single entries,
\ventry\v905. families, and entries in families of  entries.   Finally,  names  can
denote \vattributes\v405. of any of the foregoing.
    name ::= simple_name
       | character_literal  | operator_symbol
       | \vindexed_component\v402.  | slice
       | \vselected_component\v404. | attribute
    simple_name ::= identifier
    prefix ::= name | function_call
A  simple  name  for an \ventity\v301. is either the \videntifier\v203. associated with the
entity by its \vdeclaration\v301., or another identifier associated with the entity
by a \vrenaming declaration\v805..
Certain forms  of  name  (indexed  and  selected  \vcomponents\v305.,  slices,  and
attributes)  include a prefix that is either a name or a \vfunction call\v606..  If
the \vtype\v305. of a prefix is an \vaccess type\v330., then the prefix must not be a  name
that denotes a \vformal parameter\v601. of \vmode\v601. out or a \vsubcomponent\v305. thereof.
If  the  prefix  of  a  name  is  a  function call, then the name denotes a
component, a slice, an attribute, an entry, or an \ventry family\v905.,  either  of
the  result  of the function call, or (if the result is an \vaccess value\v330.) of
the \vobject\v303. designated by the result.
A prefix is said to be appropriate for a type in either  of  the  following
cases:
  -  The type of the prefix is the type considered.
  -  The type of the prefix is an access type whose \vdesignated type\v330. is  the
     type considered.
The  \vevaluation\v411.  of a name determines the entity denoted by the name.  This
evaluation has no other effect  for  a  name  that  is  a  simple  name,  a
\vcharacter literal\v207., or an \voperator symbol\v601..
The  evaluation  of a name that has a prefix includes the evaluation of the
prefix, that is, of the corresponding name or function call.  If  the  type
of  the prefix is an access type, the evaluation of the prefix includes the
determination of the object designated by the corresponding  access  value;
the  \vexception  CONSTRAINT_ERROR\v1101.  is raised if the value of the prefix is a
\vnull access value\v330., except in the case of the  prefix  of  a  representation
attribute (see 13.7.2).
Examples of simple names:
    PI      --  the simple name of a number               (see 3.2.2)
    LIMIT   --  the simple name of a constant             (see 3.2.1)
    COUNT   --  the simple name of a scalar variable      (see 3.2.1)
    BOARD   --  the simple name of an array variable      (see 3.6.1)
    MATRIX  --  the simple name of a type                 (see 3.6)
    RANDOM  --  the simple name of a function             (see 6.1)
    ERROR   --  the simple name of an exception           (see 11.1)
More details:
 4.1.1  \vIndexed Components\v402.
 4.1.2  \vSlices\v403.
 4.1.3  \vSelected Components\v404.
 4.1.4  \vAttributes\v405.
4.1.1  \uIndexed Components\n
An  indexed \vcomponent\v305. denotes either a \vcomponent of an array\v321. or an \ventry\v905. in
a family of entries.
    indexed_component ::= prefix(expression {, expression})
In the case of a component of an array, the prefix must be \vappropriate  for\v401.
\van array type\v401..  The \vexpressions\v410. specify the \vindex\v321. values for the component;
there  must  be  one  such  expression for each index position of the \varray\v321.
\vtype\v321..  In the case of an entry in a family of entries, the prefix must be a
\vname\v401. that denotes an  \ventry family\v905. of a \vtask  object\v902.,  and  the  expression
(there  must  be  exactly one) specifies the index value for the individual
entry.
Each expression must be of the type of the corresponding  index.   For  the
\vevaluation\v411.  of  an  indexed  component,  the prefix and the expressions are
evaluated \vin some order\v108. that is not defined by the language.  The exception
\vCONSTRAINT_ERROR\v1101. is raised if an index value does not belong to  the  range
of the corresponding index of the prefixing array or entry family.
Examples of indexed components:
 MY_SCHEDULE(SAT)     --  a component of a one-dimensional array (s. 3.6.1)
 PAGE(10)             --  a component of a one-dimensional array (see 3.6)
 BOARD(M, J + 1)      --  a component of a two-dimensional array (s. 3.6.1)
 PAGE(10)(20)         --  a component of a component             (see 3.6)
 REQUEST(MEDIUM)      --  an entry in a family of entries        (see 9.5)
 NEXT_FRAME(L)(M, N)  --  a component of a \vfunction call\v606.         (see 6.1)
Notes on the \uExamples:\n
Distinct notations are used for components of multidimensional arrays (such
as  BOARD) and arrays of arrays (such as PAGE).  The components of an array
of arrays are arrays and  can  therefore  be  indexed.   Thus  PAGE(10)(20)
denotes  the 20th component of PAGE(10).  In the last example NEXT_FRAME(L)
is  a  function  call  returning  an  access  value  which   designates   a
two-dimensional array.
4.1.2  \uSlices\n
A slice denotes a one-dimensional \varray\v321. formed by a sequence of consecutive
\vcomponents\v305.  of  a  one-dimensional  array.   A  slice  of  a  \vvariable\v303. is a
variable;  a slice of a \vconstant\v303. is a constant;  a slice of a  value  is  a
value.
    slice ::= prefix(\vdiscrete_range\v321.)
The \vprefix\v401. of a slice must be \vappropriate for a one-dimensional array type\v401..
The  \vtype\v305.  of the slice is the \vbase type\v305. of this \varray type\v321..  \vThe bounds of\v322.
\vthe discrete range\v322. define those of the slice and must be of the type of the
\vindex\v321.;  the slice is a null slice denoting a \vnull  array\v322.  if  the  discrete
range is a \vnull range\v310..
For  the  \vevaluation\v411. of a \vname\v401. that is a slice, the prefix and the discrete
range are evaluated in some order that is not defined by the language.  The
\vexception CONSTRAINT_ERROR\v1101. is raised by the evaluation of  a  slice,  other
than  a  null  slice,  if  any of the bounds of the discrete range does not
belong to the \vindex range\v321. of the prefixing array.  (The bounds  of  a  null
slice need not \vbelong to the subtype\v305. of the index.)
Examples of slices:
  STARS(1 .. 15)        --  a slice of 15 characters       (see 3.6.3)
  PAGE(10 .. 10 + SIZE) --  a slice of 1 + SIZE components (s. 3.6 & 3.2.1)
  PAGE(L)(A .. B)       --  a slice of the array PAGE(L)   (see 3.6)
  STARS(1 .. 0)         --  a null slice                   (see 3.6.3)
  MY_SCHEDULE(WEEKDAY)  --  bounds given by subtype        (s. 3.6 & 3.5.1)
  STARS(5 .. 15)(K)     --  same as STARS(K)               (see 3.6.3)
                        --  provided that K is in 5 .. 15
\uNotes:\n
For  a  one-dimensional  array  A,  the  name  A(N  .. N) is a slice of one
component;  its type is the base type of A.  On the other hand, A(N)  is  a
component of the array A and has the corresponding component type.
4.1.3  \uSelected Components\n
Selected  components  are  used to denote \vrecord components\v325., entries, entry
families, and objects \vdesignated\v330. by \vaccess values\v330.; they are  also  used  as
expanded names as described below.
    selected_component ::= prefix.selector
    selector ::= simple_name
       | \vcharacter_literal\v207. | Operator_symbol | \uall\n
The  following  four  forms  of  selected  components  are used to denote a
\vdiscriminant\v305., a record component, an \ventry\v905., or an \vobject\v303. designated  by  an
access value:
(a)  A discriminant:
     The  selector  must  be  a  simple  name denoting a discriminant of an
     object or value.  The \vprefix\v401. must be \vappropriate for the type\v401. of  this
     object or value.
(b)  A \vcomponent of a record\v325.:
     The  selector  must  be a \vsimple name\v401. denoting a component of a record
     object or value.  The prefix must be appropriate for the type of  this
     object or value.
     For  a  component of a \vvariant\v328., a check is made that the values of the
     discriminants are such  that  the  record  has  this  component.   The
     exception \vCONSTRAINT_ERROR\v1101. is raised if this check fails.
(c)  A single entry or an \ventry family\v905. of a \vtask\v900.:
     The selector must be a simple name denoting a single entry or an entry
     family of a task.  The prefix must be appropriate for the type of this
     task.
(d)  An object designated by an access value:
     The  selector  must be the \vreserved word\v211. \uall\n.  The value of the prefix
     must belong to an \vaccess type\v330..
A selected component of one  of  the  remaining  two  forms  is  called  an
expanded  name.   In each case the selector must be either a simple name, a
character literal, or an \voperator symbol\v601..  A \vfunction call\v606. is  not  allowed
as the prefix of an expanded name.  An expanded name can denote:
(e)  An \ventity\v301. declared in the \vvisible part\v328. of a \vpackage\v700.:
     The  prefix  must denote the package.  The selector must be the simple
     name, character literal, or \voperator\v411. symbol of the entity.
(f)  An  entity  whose  \vdeclaration\v301.  \voccurs  immediately\v801.  within  a   named
     construct:
     The  prefix  must  denote a construct that is either a \vprogram unit\v600., a
     \vblock statement\v507., a \vloop statement\v506., or an  \vaccept  statement\v905..   In  the
     case of an accept statement, the prefix must be either the simple name
     of  the  entry or entry family, or an expanded name ending with such a
     simple name (that is, no \vindex\v321. is allowed).  The selector must be  the
     simple  name, character literal, or operator symbol of an entity whose
     declaration occurs immediately within the construct.
     This form of expanded name is only allowed within the construct itself
     (including the body and any \vsubunits\v1004., in the case of a program  unit).
     A  name  declared  by  a  \vrenaming  declaration\v805.  is not allowed as the
     prefix.  If the prefix is the name of a \vsubprogram\v600. or accept statement
     and if there is more than one visible enclosing subprogram  or  accept
     statement  of this name, the expanded name is ambiguous, independently
     of the selector.
If, according to the \vvisibility\v803. rules,  there  is  at  least  one  possible
interpretation  of  the  prefix  of  a selected component as the name of an
enclosing subprogram or accept statement,  then  the  only  interpretations
considered  are those of rule (f), as expanded names (no interpretations of
the prefix as a function call are then considered).
The evaluation of  a  name  that  is  a  selected  component  includes  the
evaluation of the prefix.
Examples of selected components:
  TOMORROW.MONTH     --  a record component                    (see 3.7)
  NEXT_CAR.OWNER     --  a record component                    (see 3.8.1)
  NEXT_CAR.OWNER.AGE --  a record component                    (see 3.8.1)
  WRITER.UNIT        --  a record component (a discriminant)   (see 3.7.3)
  MIN_CELL(H).VALUE  --  a record component of the result (see 6.1 & 3.8.1)
                     --  of the function call MIN_CELL(H)
  CONTROL.SEIZE      --  an entry of the task CONTROL     (see 9.1 and 9.2)
  POOL(K).WRITE      --  an entry of the task POOL(K)     (see 9.1 and 9.2)
  NEXT_CAR.\uall\n       --  the object designated by
                     --  the access \vvariable\v328. NEXT_CAR       (see 3.8.1)
Examples of expanded names:
  TABLE_MANAGER.INSERT --  a procedure of the visible part of a package
                           (see 7.5)
  KEY_MANAGER."<"      --  an operator of the visible part of a package
                           (see 7.4.2)
  DOT_PRODUCT.SUM      --  a variable declared in a \vprocedure body\v609.
  BUFFER.POOL          --  a variable declared in a task unit (see 9.12)
  BUFFER.READ          --  an entry of a task unit (see 9.12)
  SWAP.TEMP            --  a variable declared in a block statement (s.5.6)
  STANDARD.BOOLEAN     --  the name of a predefined type (see 8.6 and C)
Note:
For  a record with components that are other records, the above rules imply
that the simple name must be  given  at  each  level  for  the  name  of  a
subcomponent.   For  example, the name NEXT_CAR.OWNER.BIRTH.MONTH cannot be
shortened (NEXT_CAR.OWNER.MONTH is not allowed).
4.1.4  Attributes
An attribute denotes a \vbasic operation\v308. of an entity given by a \vprefix\v401..
    attribute ::= prefix'attribute_designator
    attribute_designator ::= \vsimple_name\v401. [(\vuniversal_static_expression\v422.)]
The applicable attribute designators depend on the  prefix.   An  attribute
can  be  a  basic  operation delivering a value;  alternatively it can be a
function, a \vtype\v305., or a range.  The meaning of the prefix  of  an  attribute
must   be  determinable  independently  of  the  attribute  designator  and
independently of the fact that it is the prefix of an attribute.
The attributes defined by the language  are  summarized  in  Annex  A.   In
addition,  an implementation may provide implementation-defined attributes;
their description must be given in Appendix F.  The attribute designator of
any implementation-defined attribute must not be the same as  that  of  any
language-defined attribute.
The evaluation of a \vname\v401. that is an attribute consists of the evaluation of
the prefix.
\uNotes:\n
The attribute designators DIGITS, DELTA, and RANGE have the same identifier
as  a  \vreserved word\v211..  However, no confusion is possible since an attribute
designator is always  preceded  by  an  apostrophe.   The  only  predefined
attribute  designators  that  have  a  \vuniversal  expression\v423.  are those for
certain operations of array types (see 3.6.2).
Examples of attributes:
  COLOR'FIRST        -- minimum value of the enumeration type COLOR
                        (see 3.3.1 and 3.5)
  RAINBOW'BASE'FIRST -- same as COLOR'FIRST (see 3.3.2 and 3.3.3)
  REAL'DIGITS        -- precision of the type REAL (see 3.5.7 and 3.5.8)
  BOARD'LAST(2)      -- upper bound of the second dimension of BOARD
                        (see 3.6.1 and 3.6.2)
  BOARD'RANGE(1)     -- index range of the first dimension of BOARD
                        (see 3.6.1 and 3.6.2)
  POOL(K)'TERMINATED -- TRUE if task POOL(K) is terminated (see 9.2 & 9.9)
  DATE'SIZE          -- number of bits for records of type DATE
                        (see 3.7   and 13.7.2)
  MESSAGE'ADDRESS    -- address of the record variable MESSAGE
                        (see 3.7.2 and 13.7.2)
4.2  \uLiterals\n
A literal is either a \vnumeric literal\v204., an \venumeration literal\v311., the  literal
null,  or  a  string  literal.   The  evaluation  of  a  literal yields the
corresponding value.
Numeric literals are  the  literals  of  the  \vtypes\v305.  \vuniversal_integer\v314.  and
\vuniversal_real\v316..   Enumeration literals include \vcharacter literals\v206. and yield
values of the corresponding enumeration types.  The literal null  yields  a
\vnull access value\v330. which \vdesignates\v330. no \vobjects\v303. at all.
A  string  literal  is  a  basic  operation  that  combines  a  sequence of
characters into a value of a one-dimensional \varray\v321.  of  a  \vcharacter  type\v312.;
the  bounds  of  this  array  are  determined  according  to  the rules for
positional array \vaggregates\v407. (see 4.3.2).  For a \vnull  string  literal\v330.,  the
upper  bound  is  the  predecessor,  as given by the PRED attribute, of the
lower bound.  The evaluation of a null \vstring literal\v208. raises the  exception
\vCONSTRAINT_ERROR\v1101.  if  the  lower  bound  does  not  have a predecessor (see
3.5.5).
The type of a string literal and likewise the type of the literal null must
be determinable solely from the context  in  which  this  literal  appears,
excluding the literal itself, but using the fact that the literal null is a
value  of an \vaccess type\v330., and similarly that a string literal is a value of
a one-dimensional \varray type\v321. whose \vcomponent type\v305. is a character type.
The character literals corresponding to the  \vgraphic  characters\v201.  contained
within  a string literal must be visible at the place of the string literal
(although these characters themselves are not used to determine the type of
the string literal).
\uExamples:\n
    3.14159_26536  --  a \vreal literal\v204.
    1_345          --  an \vinteger literal\v204.
    CLUBS          --  an enumeration literal
    'A'            --  a character literal
    "SOME TEXT"    --  a string literal
4.3  \uAggregates\n
An  aggregate  is  a  \vbasic operation\v308. that combines \vcomponent\v305. values into a
\vcomposite value\v305. of a \vrecord\v325. or \varray type\v321..
    aggregate ::=
       (component_association {, component_association})
    component_association ::=
       [\vchoice\v328. {| choice} => ] \vexpression\v410.
Each  component  association  associates  an  expression  with   components
(possibly  none).   A  component  association  is  said  to be named if the
components are specified explicitly by choices;  it is otherwise said to be
positional.  For  a  positional  association,  the  (single)  component  is
implicitly  specified  by  position,  in  the  order  of  the corresponding
component declarations for record components,  in  \vindex\v321.  order  for  array
components.
Named  associations  can  be  given  in  any  order  (except for the choice
others), but if both positional and named associations are used in the same
aggregate, then positional associations must occur first, at  their  normal
position.   Hence  once  a  named  association  is  used,  the  rest of the
aggregate must use only named associations.  Aggregates containing a single
component association must always be given  in  named  notation.   Specific
rules  concerning  component  associations  exist for \vrecord aggregates\v408. and
\varray aggregates\v409..
Choices in component associations have the same syntax as in \vvariant  parts\v328.
(see 3.7.3).  A choice that is a component \vsimple name\v401. is only allowed in a
record  aggregate.   For a component association, a choice that is a \vsimple\v410.
\vexpression\v410. or a \vdiscrete range\v321. is only allowed in an  array  aggregate;   a
choice  that  is  a  simple  expression  specifies  the  component  at  the
corresponding index  value;   similarly  a  discrete  range  specifies  the
components  at  the  index  values in the range.  The choice others is only
allowed in a component association if the association appears last and  has
this single choice;  it specifies all remaining components, if any.
Each  component  of  the  value defined by an aggregate must be represented
once and only once in the aggregate.  Hence each aggregate must be complete
and a given component is not allowed to  be  specified  by  more  than  one
choice.
The  \vtype\v305.  of  an aggregate must be determinable solely from the context in
which the aggregate appears, excluding the aggregate itself, but using  the
fact  that  this  type  must  be composite and not limited.  The type of an
aggregate in turn determines the required type for each of its  components.
\uNotes:\n
The  above  rule implies that the determination of the type of an aggregate
cannot use any information from within the aggregate.  In particular,  this
determination  cannot  use  the  type  of  the  expression  of  a component
association, or the form or the type of a choice.  An aggregate can  always
be  distinguished  from  an  expression enclosed by parentheses:  this is a
consequence of the fact that named notation is required  for  an  aggregate
with a single component.
More details:
 4.3.1  \vRecord Aggregates\v408.
 4.3.2  \vArray Aggregates\v409.
4.3.1  \uRecord Aggregates\n
If the \vtype\v305. of an \vaggregate\v407. is a \vrecord type\v325., the \vcomponent names\v325. given  as
\vchoices\v328.  must  denote  components  (including  discriminants) of the record
type.  If the choice others is given as a choice of a record aggregate,  it
must  represent  at  least one component.  A \vcomponent association\v407. with the
choice others or  with  more  than  one  choice  is  only  allowed  if  the
represented  components  are  all  of  the  same type.  The \vexpression\v410. of a
component  association  must  have  the  type  of  the  associated   \vrecord\v325.
\vcomponents\v325..
The  value specified for a \vdiscriminant\v305. that governs a \vvariant part\v328. must be
given by a  \vstatic  expression\v422.  (note  that  this  value  determines  which
dependent components must appear in the record value).
For  the  evaluation  of  a  record aggregate, the expressions given in the
component associations are \vevaluated\v411. \vin some order\v108. that is not  defined  by
the  language.  The expression of a named association is evaluated once for
each associated component.   A  check  is  made  that  the  value  of  each
\vsubcomponent\v305.  of the aggregate belongs to the \vsubtype\v307. of this subcomponent.
The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails.
Example of a record aggregate with positional associations:
    (4, JULY, 1776)                      --  see 3.7
Examples of record aggregates with named associations:
    (DAY => 4, MONTH => JULY, YEAR => 1776)
    (MONTH => JULY, DAY => 4, YEAR => 1776)
    (DISK, CLOSED, TRACK => 5, CYLINDER => 12)       --  see 3.7.3
    (UNIT => DISK, STATUS => CLOSED, CYLINDER => 9, TRACK => 1)
Example of component association with several choices:
    (VALUE => 0, SUCC|PRED => \unew\n CELL'(0, \unull\n, \unull\n))   --  see 3.8.1
    --  The \vallocator\v421. is evaluated twice:  SUCC and PRED designate
        different cells
Note:
For an aggregate with positional associations, discriminant  values  appear
first  since  the  \vdiscriminant  part\v326.  is  given  first  in the record type
declaration;  they must be in the same order as in the  discriminant  part.
4.3.2  \uArray Aggregates\n
If  the  \vtype\v305.  of  an  \vaggregate\v407. is a one-dimensional \varray type\v321., then each
\vchoice\v328. must specify values of the \vindex type\v321., and the  \vexpression\v410.  of  each
\vcomponent association\v407. must be of the \vcomponent type\v305..
If  the  type  of  an  aggregate  is  a  multidimensional  array  type,  an
n-dimensional aggregate is written as a one-dimensional aggregate, in which
the expression specified for each component association is  itself  written
as  an  (n-1)-dimensional  aggregate  which  is called a subaggregate;  the
\vindex subtype\v321. of the one-dimensional aggregate is given by the first  index
position  of the array type.  The same rule is used to write a subaggregate
if it is again  multidimensional,  using  successive  index  positions.   A
string literal is allowed in a multidimensional aggregate at the place of a
one-dimensional  array  of  a  character  type.  In what follows, the rules
concerning array aggregates are  formulated  in  terms  of  one-dimensional
aggregates.
Apart from a final component association with the single choice others, the
rest  (if  any) of the component associations of an array aggregate must be
either all positional or all  named.   A  \vnamed  association\v407.  of  an  array
aggregate  is only allowed to have a choice that is not static, or likewise
a choice that is a null range, if the aggregate includes a single component
association and this component association has a single choice.  An  others
choice is static if the applicable index \vconstraint\v305. is static.
The  bounds  of an array aggregate that has an others choice are determined
by the applicable \vindex constraint\v322..  An others choice is  only  allowed  if
the  aggregate  appears in one of the following contexts (which defines the
applicable index constraint):
(a)  The aggregate is an \vactual parameter\v607., a generic actual parameter,  the
     result  expression  of  a  \vfunction\v609., or the expression that follows an
     \vassignment  compound  delimiter\v502..   Moreover,  the   subtype   of   the
     corresponding  formal  parameter,  generic  \vformal parameter\v601., function
     result, or \vobject\v302. is a \vconstrained array subtype\v321..
     For an aggregate that appears  in  such  a  context  and  contains  an
     association  with an others choice, named associations are allowed for
     other associations only in the case of a (nongeneric) actual parameter
     or function result.  If the aggregate  is  a  multidimensional  array,
     this restriction also applies to each of its subaggregates.
(b)  The aggregate is the operand of a \vqualified expression\v420. whose type mark
     denotes a constrained array subtype.
(c)  The aggregate is the expression of the  component  association  of  an
     enclosing  (array  or  record) aggregate.  Moreover, if this enclosing
     aggregate is a multidimensional array aggregate then it is  itself  in
     one of these three contexts.
The  bounds  of  an array aggregate that does not have an others choice are
determined as follows.  For an aggregate that has named  associations,  the
bounds  are  determined  by  the smallest and largest choices given.  For a
positional aggregate, the lower bound is determined by the applicable index
constraint if the aggregate appears in one of the contexts (a) through (c);
otherwise, the lower bound is  given  by  S'FIRST  where  S  is  the  index
subtype;   in  either  case, the upper bound is determined by the number of
components.
The evaluation of an array aggregate that is not a subaggregate proceeds in
two steps.  First, the choices of this aggregate and of its  subaggregates,
if  any,  are  \vevaluated\v411. \vin some order\v108. that is not defined by the language.
Second,  the  expressions  of  the  component  associations  of  the  array
aggregate  are evaluated in some order that is not defined by the language;
the expression of a named association is evaluated once for each associated
component.  The evaluation of a subaggregate consists of this  second  step
(the  first step is omitted since the choices have already been evaluated).
For the evaluation of an aggregate that is not a \vnull  array\v322.,  a  check  is
made  that  the index values defined by choices belong to the corresponding
index subtypes, and also  that  the  value  of  each  \vsubcomponent\v305.  of  the
aggregate   belongs   to   the   subtype  of  this  subcomponent.   For  an
n-dimensional  multidimensional  aggregate,  a  check  is  made  that   all
(n-1)-dimensional  subaggregates  have  the  same  bounds.   The  exception
\vCONSTRAINT_ERROR\v1101. is raised if any of these checks fails.
Note:
The allowed contexts for an array aggregate including an others choice  are
such  that  the  bounds  of  such  an  aggregate  are always known from the
context.
Examples of array aggregates with \vpositional associations\v407.:
    (7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
    TABLE'(5, 8, 4, 1, others => 0)  --  see 3.6
Examples of array aggregates with named associations:
    (1 .. 5 => (1 .. 8 => 0.0))   --  two-dimensional
    (1 .. N => \unew\n CELL)          --  N new cells, in particular for N =  0
    TABLE'(2 | 4 | 10 => 1, \uothers\n => 0)
    SCHEDULE'(MON .. FRI => TRUE,  \uothers\n => FALSE)  --  see 3.6
    SCHEDULE'(WED | SUN  => FALSE, \uothers\n => TRUE)
Examples of two-dimensional array aggregates:
    -- Three aggregates for the same value of type MATRIX (see 3.6):
 ((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
 (1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
 (1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))
Examples of aggregates as initial values:
  A : TABLE := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0);        -- A(1)=7, A(10)= 8
  B : TABLE := TABLE'(2 | 4 | 10 => 1, \uothers\n => 0);  -- B(1)=0, B(10)=1
  C : \uconstant\n MATRIX := (1 .. 5 => (1 .. 8 => 0.0));
                                                 -- C'FIRST(1)=1, C'LAST(2)=8
  D : BIT_VECTOR(M .. N) := (M .. N => TRUE);  -- see 3.6
  E : BIT_VECTOR(M .. N) := (\uothers\n => TRUE);
  F : STRING(1 .. 1) := (1 => 'F');
                                  -- a one component aggregate: same as "F"
4.4  \uExpressions\n
An expression is a formula that defines the computation of a value.
    expression ::=
         \vrelation\v412. {and relation} | relation {and then relation}
       | relation {or relation}  | relation {or else relation}
       | relation {xor relation}
    relation ::=
         simple_expression [\vrelational_operator\v411. simple_expression]
       | simple_expression [not] in \vrange\v310.
       | simple_expression [not] in \vtype_mark\v307.
    simple_expression ::= [\vunary_adding_operator\v411.]
                          term {\vbinary_adding_operator\v411. term}
    term ::= factor {\vmultiplying_operator\v411. factor}
    factor ::= primary [** primary] | \uabs\n primary | not primary
    primary ::=
     \vnumeric_literal\v204. | \unull\n | \vaggregate\v407. | \vstring_literal\v208. | \vname\v401. | \vallocator\v421.
   | \vfunction_call\v606. | \vtype_conversion\v419. | \vqualified_expression\v420. | (expression)
Each primary has a value and a \vtype\v305..  The only names allowed  as  primaries
are  named  numbers;   \vattributes\v405.  that  yield  values;  and names denoting
\vobjects\v302. (the value of such a  primary  is  the  value  of  the  object)  or
denoting  values.   Names that denote formal parameters of mode out are not
allowed as primaries;  names of their subcomponents are only allowed in the
case of discriminants.
The type of an expression depends only on the type of its constituents  and
on  the  \voperators\v411. applied;  for an overloaded constituent or operator, the
determination of  the  constituent  type,  or  the  identification  of  the
appropriate   operator,  depends  on  the  context.   For  each  predefined
operator, the operand and \vresult types\v601. are given in section 4.5.
Examples of primaries:
    4.0                --  \vreal literal\v204.
    PI                 --  \vnamed number\v302.
    (1 .. 10 => 0)     --  \varray aggregate\v409.
    SUM                --  \vvariable\v303.
    INTEGER'LAST       --  attribute
    SINE(X)            --  function call
    COLOR'(BLUE)       --  qualified expression
    REAL(M*N)          --  conversion
    (LINE_COUNT + 10)  --  parenthesized expression
Examples of expressions:
    VOLUME                  -- primary
    \unot\n DESTROYED           -- factor
    2*LINE_COUNT            -- term
    -4.0                      -- simple expression
    -4.0 + A                  -- simple expression
    B**2 - 4.0*A*C            -- simple expression
    PASSWORD(1 .. 3) = "BWV"    -- relation
    COUNT \uin\n SMALL_INT          -- relation
    COUNT \unot in\n SMALL_INT      -- relation
    INDEX = 0 \uor\n ITEM_HIT         -- expression
    (COLD \uand\n SUNNY) \uor\n WARM      -- expression (parentheses are required)
    A**(B**C)                     -- expression (parentheses are required)
4.5  \uOperators and Expression Evaluation\n
The   language  defines  the  following  six  classes  of  operators.   The
corresponding operator symbols (except /=), and only those, can be used  as
\vdesignators\v601.  in declarations of functions for user-defined operators.  They
are given in the order of increasing precedence.
    logical_operator             ::=  \uand\n | \uor\n  | \uxor\n
    relational_operator          ::=  =   | /=  | <   | <= | > | >=
    binary_adding_operator       ::=  +   | -   | &
    unary_adding_operator        ::=  +   | -
    multiplying_operator         ::=  *   | /   | \umod\n | \urem\n
    highest_precedence_operator  ::=  **  | \uabs\n | \unot\n
The \vshort-circuit control\v411.  forms  and  then  and  or  else  have  the  same
precedence  as  logical operators.  The membership tests in and not in have
the same precedence as relational operators.
For a \vterm\v410., simple \vexpression\v410., \vrelation\v410., or expression, operators of higher
precedence are associated with their operands  before  operators  of  lower
precedence.   In  this  case,  for  a  sequence  of  operators  of the same
precedence level, the operators are associated in textual order  from  left
to right;  parentheses can be used to impose specific associations.
The  operands  of  a  \vfactor\v410.,  of  a  term, of a \vsimple expression\v410., or of a
relation, and the operands  of  an  expression  that  does  not  contain  a
short-circuit control form, are evaluated \vin some order\v108. that is not defined
by  the  language  (but  before application of the corresponding operator).
The right operand of a short-circuit control form is evaluated if and  only
if the left operand has a certain value (see 4.5.1).
For  each  form  of  type  declaration,  certain of the above operators are
predefined, that is, they are \vimplicitly declared\v301. by the type  declaration.
For  each  such  implicit operator declaration, the \vnames\v401. of the parameters
are LEFT and RIGHT for binary operators;  the single  parameter  is  called
RIGHT  for  unary adding operators and for the unary operators \uabs\n and \unot\n.
The effect of the predefined operators is explained  in  subsections  4.5.1
through 4.5.7.
The  predefined operations on \vinteger types\v314. either yield the mathematically
correct  result  or  raise  the  exception  \vNUMERIC_ERROR\v1101..   A   predefined
operation   that   delivers  a  result  of  an  integer  type  (other  than
\vuniversal_integer\v314.) can  only  raise  the  exception  NUMERIC_ERROR  if  the
mathematical  result is not a value of the type.  The predefined operations
on \vreal types\v316. yield results whose accuracy is defined in section 4.5.7.   A
predefined  operation  that  delivers  a  result of a real type (other than
\vuniversal_real\v316.) can only raise the exception NUMERIC_ERROR if the result is
not within the \vrange\v310. of the \vsafe numbers\v316.  of  the  type,  as  explained  in
section 4.5.7.
Examples of precedence:
    \unot\n SUNNY \uor\n WARM    --  same as (not SUNNY) or WARM
    X > 4.0 \uand\n Y > 0.0  --  same as (X > 4.0) \uand\n (Y > 0.0)
    -4.0*A**2            --  same as -(4.0 * (A**2))
    \uabs\n(1 + A) + B       --  same as (\uabs\n (1 + A)) + B
    Y**(-3)              --  parentheses are necessary
    A / B * C            --  same as (A/B)*C
    A + (B + C)          --  evaluate B + C before adding it to A
More details:
 4.5.1  \vLogical Operators and Short Circuit Control Forms\v412.
 4.5.2  \vRelational Operators and Membership Tests\v413.
 4.5.3  \vAdding Operators\v414.
 4.5.4  \vUnary Operators\v415.
 4.5.5  \vMultiplying Operators\v416.
 4.5.6  \vHighest Precedence Operations\v417.
 4.5.7  \vAccuracy of Operations with Real Operands\v418.
4.5.1  \uLogical Operators and Short-circuit Control Forms\n
The following logical \voperators\v411. are predefined for any boolean \vtype\v305. and any
one-dimensional \varray type\v321. whose components are  of  a  \vboolean  type\v313.;   in
either case the two operands have the same type.
Operator  Operation              Operand type                 Result type
\uand\n     conjunction            any boolean type             same bool. type
                               array of boolean components  same array type
\uor\n      inclusive disjunction  any boolean type             same bool. type
                               array of boolean components  same array type
\uxor\n     exclusive disjunction  any boolean type             same bool. type
                               array of boolean components  same array type
The \voperations\v305. on arrays are performed on a component-by-component basis on
matching  components,  if  any (as for equality, see 4.5.2).  The bounds of
the resulting array are those of the left operand.  A check  is  made  that
for each component of the left operand there is a matching component of the
right operand, and vice versa.  The \vexception CONSTRAINT_ERROR\v1101. is raised if
this check fails.
The  short-circuit  control  forms and then and or else are defined for two
operands of a boolean type and deliver a result of the same type.  The left
operand of a short-circuit control form is always evaluated first.  If  the
left  operand  of an expression with the control form and then evaluates to
FALSE, the right operand is not evaluated and the value of  the  expression
is  FALSE.   If  the left operand of an expression with the control form or
else evaluates to TRUE, the right operand is not evaluated and the value of
the expression is TRUE.  If both operands are evaluated, and then  delivers
the same result as and, and or else delivers the same result as or.
Note:
The  conventional  meaning  of  the  logical operators is given by the fol-
lowing truth table:
    A        B       (A \uand\n B)    (A or B)    (A xor B)
    TRUE    TRUE     TRUE         TRUE        FALSE
    TRUE    FALSE    FALSE        TRUE        TRUE
    FALSE   TRUE     FALSE        TRUE        TRUE
    FALSE   FALSE    FALSE        FALSE       FALSE
Examples of logical operators:
    SUNNY \uor\n WARM
    FILTER(1 .. 10) \uand\n FILTER(15 .. 24)   --   see 3.6.1
Examples of short-circuit control forms:
    NEXT_CAR.OWNER /= \unull and then\n NEXT_CAR.OWNER.AGE > 25   -- see 3.8.1
    N = 0 \uor else\n A(N) = HIT_VALUE
4.5.2  \uRelational Operators and Membership Tests\n
The  equality  and inequality \voperators\v411. are \vpredefined\v411. for any \vtype\v305. that is
not limited.  The other relational operators are the ordering  operators  <
(less  than),  <=  (less  than or equal), > (greater than), and >= (greater
than or equal).  The ordering operators   are  predefined  for  any  \vscalar\v310.
\vtype\v310.,  and  for  any  discrete \varray type\v321., that is, a one-dimensional array
type whose \vcomponents\v305. are  of  a  \vdiscrete  type\v310..   The  operands  of  each
predefined  relational operator have the same type.  The result type is the
\vpredefined type BOOLEAN\v313..
The relational operators have their conventional meaning:   the  result  is
equal  to  TRUE  if the corresponding relation is satisfied;  the result is
FALSE otherwise.  The inequality operator gives the complementary result to
the equality operator:  FALSE if equal, TRUE if not equal.
    Operator    \vOperation\v305.                 Operand type          Result type
    = /=        equality and inequality   any type              BOOLEAN
    < <= > >=   test for ordering         any scalar type       BOOLEAN
                                          discrete array type   BOOLEAN
Equality for the discrete types  is  equality  of  the  values.   For  real
operands  whose  values  are  nearly  equal,  the results of the predefined
relational operators are given in section 4.5.7.   Two  \vaccess  values\v330.  are
equal either if they \vdesignate\v330. the same \vobject\v303., or if both are equal to the
\vnull value\v330. of the access type.
For  two  array  values  or  two  record  values of the same type, the left
operand is equal to the right operand if and only if for each component  of
the  left  operand  there  is a matching component of the right operand and
vice versa;  and the values of matching components are equal, as  given  by
the  predefined  equality  operator for the component type.  In particular,
two \vnull arrays\v322. of the same type are always equal;  two \vnull records\v325. of the
same type are always equal.
For comparing two records of the same type, matching components  are  those
which have the same \vcomponent identifier\v325..
For  comparing  two  one-dimensional  arrays  of  the  same  type, matching
components are those (if any) whose index values  match  in  the  following
sense:   the lower bounds of the index \vranges\v310. are defined to match, and the
\vsuccessors\v315. of matching indices are defined to  match.   For  comparing  two
multidimensional  arrays,  matching components are those whose index values
match in successive index positions.
If equality is explicitly defined for a \vlimited type\v708., it does not extend to
\vcomposite  types\v305.  having  \vsubcomponents\v305.  of  the  limited  type   (explicit
definition of equality is allowed for such composite types).
The ordering operators <, <=, >, and >= that are defined for discrete array
types correspond to lexicographic order using the predefined order relation
of  the  \vcomponent  type\v305..   A null array is lexicographically less than any
array having at least one component.  In the case of  nonnull  arrays,  the
left  operand is lexicographically less than the right operand if the first
component of the left operand is less than that of  the  right;   otherwise
the  left  operand is lexicographically less than the right operand only if
their first components are equal and  the  tail  of  the  left  operand  is
lexicographically  less  than  that  of the right (the tail consists of the
remaining components beyond the first and can be null).
The membership tests in and not in  are  predefined  for  all  types.   The
result  type  is the predefined type BOOLEAN.  For a membership test with a
range, the \vsimple expression\v410. and the bounds of the range  must  be  of  the
same  scalar type;  for a membership test with a \vtype mark\v307., the type of the
simple expression must be the \vbase type\v305. of the type mark.   The  \vevaluation\v411.
of the membership test in yields the result TRUE if the value of the simple
expression  is  within  the  given  range,  or if this value \vbelongs to the\v305.
\vsubtype\v305. denoted by the given type mark;  otherwise this  evaluation  yields
the  result  FALSE (for a value of a real type, see 4.5.7).  The membership
test not in gives the complementary result to the membership test in.
\uExamples:\n
    X /= Y
    "" < "A" \uand\n "A" < "AA"     --  TRUE
    "AA" < "B" \uand\n "A" < "A  "  --  TRUE
    MY_CAR = \unull\n              -- true if MY_CAR has been set to null
                                  (see 3.8.1)
    MY_CAR = YOUR_CAR          -- true if we both share the same car
    MY_CAR.\uall\n = YOUR_CAR.\uall\n  -- true if the two cars are identical
    N \unot in\n 1 .. 10     -- range membership test
    TODAY \uin\n MON .. FRI  -- range membership test
    TODAY \uin\n WEEKDAY     -- subtype membership test (see 3.5.1)
    ARCHIVE \uin\n DISK_UNIT -- subtype membership test (see 3.7.3)
\uNotes:\n
No \vexception\v1100. is ever raised by a predefined relational  operator  or  by  a
membership  test,  but  an exception can be raised by the evaluation of the
operands.
If a \vrecord type\v325. has components that depend on discriminants, two values of
this type have matching components if and only if their  discriminants  are
equal.   Two  nonnull  arrays  have  matching components if and only if the
value of the attribute LENGTH(N) for each \vindex\v321. position N is the same  for
both.
4.5.3  \uBinary Adding Operators\n
The binary adding \voperators\v411. + and -  are predefined for  any  \vnumeric  type\v310.
and  have  their  conventional  meaning.   The  catenation  operators & are
predefined for any one-dimensional \varray type\v321. that is not limited.
 +-Operator
 |   \vOperation\v305.  Left operand \vtype\v305.  Right operand type    Result type
+----------------------------------------------------------------------+
|+ |  addition |any numeric type  |same numeric type |same numeric type|
|  |           |                  |                  |                 |
|- |subtraction|any numeric type  |same numeric type |same numeric type|
|  |           |                  |                  |                 |
|& |catenation |any array type    |same array type   |same array type  |
|  |           |any array type    |the \vcomponent type\v305.|same array type  |
|  |           |the component type|any array type    |same array type  |
|  |           |the component type|the component type|any array type   |
+----------------------------------------------------------------------+
For \vreal types\v316., the accuracy of the result is  determined  by  the  operand
type (see 4.5.7).
If  both  operands are one-dimensional arrays, the result of the catenation
is a one-dimensional array whose length is the sum of the  lengths  of  its
operands,  and whose components comprise the components of the left operand
followed by the components of the right operand.  The lower bound  of  this
result is the lower bound of the left operand, unless the left operand is a
\vnull  array\v322.,  in  which  case  the  result  of  the catenation is the right
operand.
If either operand is of the component type of an array type, the result  of
the  catenation is given by the above rules, using in place of this operand
an array having this operand as its only component  and  having  the  lower
bound of the \vindex subtype\v321. of the array type as its lower bound.
The  \vexception  CONSTRAINT_ERROR\v1101. is raised by catenation if the upper bound
of the result exceeds the \vrange of the index subtype\v322., unless the result  is
a  null  array.   This  exception  is  also raised if any operand is of the
component type but has a value  that  does  not  belong  to  the  component
subtype.
\uExamples:\n
    Z + 0.1      --  Z must be of a real type
    "A" & "BCD"  --  catenation of two \vstring literals\v208.
    'A' & "BCD"  --  catenation of a \vcharacter literal\v207. and a string literal
    'A' & 'A'    --  catenation of two character literals
4.5.4  \uUnary Adding Operators\n
The  unary adding \voperators\v411. + and - are predefined for any \vnumeric type\v310. and
have their conventional meaning.  For each of these operators, the  operand
and the result have the same \vtype\v305..
    Operator   Operation   Operand type       Result type
    +          identity    any numeric type   same numeric type
    -          negation    any numeric type   same numeric type
4.5.5  \uMultiplying Operators\n
The operators * and / are predefined for any integer and any \vfloating point\v317.
\vtype\v317. and have their conventional meaning;  the operators mod  and  rem  are
predefined for any \vinteger type\v314..  For each of these operators, the operands
and  the  result  have  the  same \vbase type\v305..  For floating point types, the
accuracy of the result is determined by the operand type (see 4.5.7).
 Operator     Operation          Operand type           Result type
   *          multiplication     any integer type       same integer type
                                 any floating point     same floating point
                                 type                   type
   /          integer division   any integer type       same integer type
              floating division  any floating point     same floating point
                                 type                   type
  \nmod\n         modulus            any integer type       same integer type
  \urem\n         remainder          any integer type       same integer type
Integer division and remainder are defined by the relation
    A = (A/B)*B + (A \urem\n B)
where (A rem B) has the sign of A and  an  absolute  value  less  than  the
absolute value of B.  Integer division satisfies the identity
    (-A)/B = -(A/B) = A/(-B)
The  result of the modulus operation is such that (A mod B) has the sign of
B and an absolute value less than the absolute value of  B;   in  addition,
for some integer value N, this result must satisfy the relation
    A = B*N + (A \umod\n B)
For  each  \vfixed  point  type\v319.,  the  following  multiplication and division
operators, with an operand of the predefined type INTEGER, are  predefined.
 Operator   Operation   Left operand      Right operand     Result type
                        type              type
   *        multiply    any fixed point   INTEGER           same as left
                        type
                        INTEGER           any fixed point   same as right
                                          type
   /        division    any fixed point   INTEGER           same as left
                        type
Integer  multiplication  of  fixed  point  values is equivalent to repeated
addition.  Division of a fixed point value by an integer does not involve a
change in type but is approximate (see 4.5.7).
Finally, the following multiplication and division operators  are  declared
in  the  \vpredefined package STANDARD\v806..  These two special operators apply to
operands of all fixed point types (it is a consequence of other rules  that
they cannot be renamed or given as generic \vactual parameters\v607.).
Operator  Operation  Left operand      Right operand      Result type
                     type              type
  *       multiply   any fixed point   any fixed point    universal_fixed
                     type              type
  /       divide     any fixed point   any fixed point    universal_fixed
                     type              type
Multiplication of operands of the same or of different fixed point types is
exact  and  delivers  a result of the anonymous predefined fixed point type
universal_fixed whose delta is arbitrarily small.  The result of  any  such
multiplication  must  always  be explicitly converted to some \vnumeric type\v310..
This ensures explicit control of the accuracy of the computation.  The same
considerations apply to division of a fixed point value  by  another  fixed
point  value.  No other operators are defined for the type universal_fixed.
The exception \vNUMERIC_ERROR\v1101. is raised by integer division, rem, and mod  if
the right operand is zero.
\uExamples:\n
    I : INTEGER := 1;
    J : INTEGER := 2;
    K : INTEGER := 3;
    X : REAL \udigits\n 6 := 1.0;             --     see 3.5.7
    Y : REAL \udigits\n 6 := 2.0;
    F : FRACTION \udelta\n 0.0001  := 0.1;        --     see 3.5.9
    G : FRACTION \udelta\n 0.0001  := 0.1;
    Expression        Value     Result Type
    I*J               2         same as I and J, that is, INTEGER
    K/J               1         same as K and J, that is, INTEGER
    K \umod\n J           1         same as K and J, that is, INTEGER
    X/Y               0.5       same as X and Y, that is, REAL
    F/2               0.05      same as F, that is, FRACTION
    3*F               0.3       same as F, that is, FRACTION
    F*G               0.01      universal_fixed, conversion needed
    FRACTION(F*G)     0.01      FRACTION, as stated by the conversion
    REAL(J)*Y         4.0       REAL, the type of both operands after
                                conversion of J
\uNotes:\n
For positive A and B, A/B is the quotient and A rem B is the remainder when
A  is  divided  by  B.   The  following  relations are satisfied by the rem
operator:
    A    \urem\n (-B) =   A \urem\n B
    (-A) \urem\n   B  = -(A \urem\n B)
For any integer K, the following identity holds:
      A  \umod\n   B  =  (A + K*B) \umod\n B
The  relations  between  integer  division,  remainder,  and  modulus   are
illustrated by the following table:
   A      B   A/B   A \urem\n B  A \umod\n B     A     B    A/B   A \urem\n B   A \umod\n B
   10     5    2       0        0       -10    5    -2       0         0
   11     5    2       1        1       -11    5    -2      -1         4
   12     5    2       2        2       -12    5    -2      -2         3
   13     5    2       3        3       -13    5    -2      -3         2
   14     5    2       4        4       -14    5    -2      -4         1
   10    -5   -2       0        0       -10   -5     2       0         8
   11    -5   -2       1       -4       -11   -5     2      -1        -1
   12    -5   -2       2       -3       -12   -5     2      -2        -2
   13    -5   -2       3       -2       -13   -5     2      -3        -3
   14    -5   -2       4       -1       -14   -5     2      -4        -4
4.5.6  \uHighest Precedence Operators\n
The highest precedence unary operator \uabs\n is  predefined  for  any  numeric
type.   The  highest  precedence  unary  operator not is predefined for any
\vboolean type\v313. and any one-dimensional \varray type\v321.  whose  components  have  a
boolean type.
 Operator   Operation          Operand type                  Result type
  \uabs\n      absolute value     any numeric type              same numeric type
  \unot\n      logical negation   any boolean type              same boolean type
                              array of boolean components   same array type
The  operator  not  that  applies  to  a  one-dimensional  array of boolean
components yields a one-dimensional boolean array  with  the  same  bounds;
each  component  of  the  result  is  obtained  by  logical negation of the
corresponding component of the operand (that is, the component that has the
same \vindex\v321. value).
The highest precedence exponentiating operator ** is  predefined  for  each
\vinteger  type\v314.  and  for each \vfloating point type\v319..  In either case the right
operand, called the exponent, is of the predefined type INTEGER.
 Operator  Operation      Left operand         Right operand   Result type
                          type                 type
   **     exponentiation  any integer type     INTEGER         same as left
                          any floating point   INTEGER         same as left
                          type
Exponentiation  with  a  positive  exponent  is  equivalent   to   repeated
\vmultiplication\v416.  of the left operand by itself, as indicated by the exponent
and from left to right.  For an operand  of  a  floating  point  type,  the
exponent  can be negative, in which case the value is the reciprocal of the
value with the  positive  exponent.   Exponentiation  by  a  zero  exponent
delivers  the  value  one.   Exponentiation of a value of a floating  point
type is approximate (see 4.5.7).  Exponentiation of an integer  raises  the
exception \vCONSTRAINT_ERROR\v1101. for a negative exponent.
4.5.7 \uAccuracy of Operations with Real Operands\n
A  real  \vsubtype\v305.  specifies  a  set  of  model  numbers.  Both the accuracy
required from any basic or \vpredefined operation\v308. giving a real  result,  and
the  result of any predefined \vrelation\v410. between real operands are defined in
terms of these \vmodel numbers\v316..
A model interval of a subtype  is  any  interval  whose  bounds  are  model
numbers  of  the  subtype.  The model interval associated with a value that
belongs to a real subtype is the smallest model interval (of  the  subtype)
that  includes  the  value.   (The  model  interval associated with a model
number of a subtype consists of that number only.)
For any \vbasic operation\v308. or predefined operator that yields a  result  of  a
real  subtype,  the  required  bounds  on  the  result are given by a model
interval defined as follows:
  -  The result model interval is  the  smallest  model  interval  (of  the
     result  subtype)  that includes the minimum and the maximum of all the
     values obtained by applying the (exact) mathematical  operation,  when
     each  operand is given any value of the model interval (of the operand
     subtype) defined for the operand.
  -  The model interval of an operand that  is  itself  the  result  of  an
     operation,  other  than  an  implicit  conversion, is the result model
     interval of this operation.
  -  The model interval of an operand whose value is obtained  by  implicit
     conversion  of a \vuniversal expression\v401. is the model interval associated
     with this value within the operand subtype.
The result model interval is undefined if the absolute value of one of  the
above  mathematical  results  exceeds the largest \vsafe number\v316. of the result
type.  Whenever the result  model  interval  is  undefined,  it  is  highly
desirable  that the exception \vNUMERIC_ERROR\v1101. be raised if the implementation
cannot produce an actual result that is in the \vrange\v311. of safe numbers.  This
is, however, not required by the language rules, in recognition of the fact
that certain target machines do  not  permit  easy  detection  of  overflow
situations.  The value of the \vattribute\v405. \vMACHINE_OVERFLOWS\v1309. indicates whether
the   target   machine  raises  the  exception  NUMERIC_ERROR  in  overflow
situations (see 13.7.3).
The safe numbers of a \vreal type\v316. are defined (see 3.5.6) as  a  superset  of
the  model  numbers,  for  which  \verror bounds\v316. follow the same rules as for
model numbers.  Any definition given in this  section  in  terms  of  model
intervals  can  therefore be extended to safe intervals of safe numbers.  A
consequence of this extension is that an implementation is not  allowed  to
raise  the  exception  NUMERIC_ERROR  when  the  result  interval is a safe
interval.
For the result of \vexponentiation\v417., the model interval defining the bounds on
the result is obtained by applying the  above  rules  to  the  sequence  of
\vmultiplications\v416.  defined  by the exponent, and to the final division in the
case of a negative exponent.
For the result of a relation between two real operands, consider  for  each
operand  the  model  interval  (of  the  operand  subtype)  defined for the
operand;  the result can be any value obtained by applying the mathematical
comparison to values arbitrarily chosen in the corresponding operand  model
intervals.   If  either or both of the operand model intervals is undefined
(and if neither of the operand evaluations raises an  exception)  then  the
result  of  the  comparison  is  allowed to be any possible value (that is,
either TRUE or FALSE).
The result of a \vmembership test\v413. is defined in terms of comparisons  of  the
operand  value  with  the lower and upper bounds of the given range or type
mark (the usual rules apply to these comparisons).
Note:
For a \vfloating point type\v319. the numbers 15.0, 3.0, and 5.0 are  always  model
numbers.  Hence X/Y where X equals 15.0 and Y equals 3.0 yields exactly 5.0
according to the above rules.  In the general case, division does not yield
model numbers and in consequence one cannot assume that (1.0/X)*X = 1.0.
4.6  \uType Conversions\n
The evaluation of an  explicit \vtype\v305.  conversion  evaluates  the  \vexpression\v410.
given  as  the  operand,  and  converts  the resulting value to a specified
target type.  Explicit type conversions are allowed between closely related
types as defined below.
    type_conversion ::= type_mark(expression)
The target type of a type conversion is the \vbase type\v305.  of  the  type  mark.
The  type  of  the  operand  of  a  type  conversion  must  be determinable
independently of the context (in particular, independently  of  the  target
type).   Furthermore, the operand of a type conversion is not allowed to be
a literal null, an allocator,  an  aggregate,  or  a  string  literal;   an
expression  enclosed  by  parentheses  is  allowed as the operand of a type
conversion only if the expression alone is allowed.
A conversion to a \vsubtype\v305. consists of  a  conversion  to  the  target  type
followed  by  a  check  that  the  result  of the conversion \vbelongs to the\v305.
\vsubtype\v305..  A conversion of an operand of a given type to the type itself  is
allowed.
The  other  allowed  explicit  type conversions correspond to the following
three cases:
(a)  Numeric types
     The operand can be of any numeric type;  the value of the  operand  is
     converted  to  the target type which must also be a numeric type.  For
     conversions involving \vreal types\v316., the result is within the accuracy of
     the specified subtype (see 4.5.7).  The conversion of a real value  to
     an  integer  type  rounds  to  the nearest integer;  if the operand is
     halfway between two integers (within the accuracy of the real subtype)
     rounding may be either up or down.
(b)  \vDerived types\v309.
     The conversion is allowed if one of the target type  and  the  operand
     type  is  derived  from the other, directly or indirectly, or if there
     exists a third type from which both types  are  derived,  directly  or
     indirectly.
(c)  \vArray types\v321.
     The  conversion is allowed if the operand type and the target type are
     array types that satisfy the following conditions:   both  types  must
     have the same dimensionality;  for each \vindex\v321. position the \vindex types\v321.
     must  either  be  the  same  or  be  convertible  to  each other;  the
     \vcomponent\v305. types must be the same;  finally, if the component type is a
     type with discriminants or an access type, the component subtypes must
     be either both constrained or both unconstrained.  If  the  type  mark
     denotes  an  \vunconstrained  array type\v321., then, for each index position,
     the bounds of the result are obtained by converting the bounds of  the
     operand  to  the  corresponding index type of the target type.  If the
     \vtype mark\v307. denotes a \vconstrained array subtype\v321., then the bounds of  the
     result  are those imposed by the type mark.  In either case, the value
     of each component of the result is that of the \vmatching  component\v413.  of
     the operand (see 4.5.2).
In  the  case  of  conversions  of  numeric  types  and  derived types, the
exception \vCONSTRAINT_ERROR\v1101. is raised by the evaluation of a type conversion
if the result of the conversion fails to satisfy a  constraint  imposed  by
the type mark.
In  the  case  of  array  types, a check is made that any constraint on the
component subtype is the same for the operand array type as for the  target
array  type.   If  the type mark denotes an unconstrained array type and if
the operand is not a \vnull array\v322., then, for each index position, a check  is
made  that  the  bounds  of  the  result  belong to the corresponding index
subtype of the target type.  If the type mark denotes a  constrained  array
subtype,  a check is made that for each component of the operand there is a
matching component of the target subtype, and vice  versa.   The  exception
CONSTRAINT_ERROR is raised if any of these checks fails.
If a conversion is allowed from one type to another, the reverse conversion
is  also allowed. This reverse conversion is used where an \vactual parameter\v607.
of \vmode\v601. in out or out has the form of a type  conversion  of  a  (\vvariable\v303.)
\vname\v401. as explained in section 6.4.1.
Apart  from  the  explicit  type conversions, the only allowed form of type
conversion  is  the  implicit  conversion  of   a   value   of   the   type
\vuniversal_integer\v314. or \vuniversal_real\v316. into another \vnumeric type\v310..  An implicit
conversion of an operand of type universal_integer to another integer type,
or  of  an operand of type universal_real to another real type, can only be
applied if the operand is either a \vnumeric literal\v204., a \vnamed number\v302.,  or  an
\vattribute\v405.;   such  an  operand is called a convertible universal operand in
this section.  An implicit conversion of a convertible universal operand is
applied if and only if the innermost complete context (see 8.7)  determines
a unique (numeric) target type for the implicit conversion, and there is no
legal interpretation of this context without this conversion.
\uNotes:\n
The  rules  for  implicit  conversions imply that no implicit conversion is
ever applied to the operand of an  explicit  type  conversion.   Similarly,
implicit  conversions  are  not  applied  if  both operands of a predefined
relational operator are convertible universal operands.
The language allows implicit subtype conversions in the case of array types
(see 5.2.1).  An explicit type conversion can have the effect of  a  change
of  \vrepresentation\v1301. (in particular see 13.6).  Explicit conversions are also
used for actual parameters (see 6.4).
Examples of numeric type conversion:
    REAL(2*J)      --  value is converted to \vfloating point\v317.
    INTEGER(1.6)   --  value is 2
    INTEGER(-0.4)  --  value is 0
Example of conversion between derived types:
    type A_FORM is new B_FORM;
    X : A_FORM;
    Y : B_FORM;
    X := A_FORM(Y);
    Y := B_FORM(X);  --  the reverse conversion
Examples of conversions between array types:
    \utype\n SEQUENCE \uis array\n (INTEGER \urange\n <>) \uof\n INTEGER;
    \usubtype\n DOZEN \uis\n SEQUENCE(1 .. 12);
    LEDGER : \uarray\n(1 .. 100) \uof\n INTEGER;
    SEQUENCE(LEDGER)            --  bounds are those of LEDGER
    SEQUENCE(LEDGER(31 .. 42))  --  bounds are 31 and 42
    DOZEN(LEDGER(31 .. 42))     --  bounds are those of DOZEN
Examples of implicit conversions:
    X : INTEGER := 2;
    X + 1 + 2              -- implicit conversion of each integer literal
    1 + 2 + X              -- implicit conversion of each integer literal
    X + (1 + 2)            -- implicit conversion of each integer literal
    2 = (1 + 1)            -- no implicit conversion:  the type is uni-
                              versal_integer
    A'LENGTH = B'LENGTH    -- no implicit conversion:  the type is uni-
                              versal_integer
    C : \uconstant\n := 3 + 2; -- no implicit conversion:  the type is uni-
                              versal_integer
    X = 3 \uand\n 1 = 2        -- implicit conversion of 3, but not of 1 and 2
4.7  \uQualified Expressions\n
A  qualified  \vexpression\v410. is used to state explicitly the \vtype\v305., and possibly
the \vsubtype\v305., of an operand that is the given expression or \vaggregate\v407..
    qualified_expression ::=
       type_mark'(expression) | type_mark'aggregate
The operand must have the same type as the \vbase type\v305. of the \vtype mark\v307..  The
value of  a  qualified  expression  is  the  value  of  the  operand.   The
evaluation  of a qualified expression evaluates the operand and checks that
its value belongs to the subtype denoted by the type mark.   The  exception
\vCONSTRAINT_ERROR\v1101. is raised if this check fails.
\uExamples:\n
    \utype\n MASK \uis\n (FIX, DEC, EXP, SIGNIF);
    \utype\n CODE \uis\n (FIX, CLA, DEC, TNZ, SUB);
    PRINT (MASK'(DEC));  --  DEC is of type MASK
    PRINT (CODE'(DEC));  --  DEC is of type CODE
    \ufor\n J \uin\n CODE'(FIX) .. CODE'(DEC) \uloop\n ... -- qualification needed for
                                                  either FIX or DEC
    \ufor\n J \uin\n CODE \urange\n FIX .. DEC \uloop\n ...    -- qualification unnecessary
    \ufor\n J \uin\n CODE'(FIX) .. DEC \uloop\n ...        -- qualification unnecessary
                                                  for DEC
    DOZEN'(1 | 3 | 5 | 7 => 2, \uothers\n => 0) -- see 4.6
\uNotes:\n
Whenever  the type of an \venumeration literal\v311. or aggregate is not known from
the context,  a  qualified  expression  can  be  used  to  state  the  type
explicitly.   For  example,  an  overloaded  enumeration  literal  must  be
qualified in the  following  cases:   when  given  as  a  parameter   in  a
\vsubprogram\v600.  call  to  an  overloaded  subprogram  that  cannot otherwise be
identified on the basis of  remaining  parameter  or  result  types,  in  a
relational  expression  where  both  operands  are  overloaded  enumeration
literals, or in an \varray\v321. or \vloop parameter\v506.  range  where  both  bounds  are
overloaded  enumeration  literals.   Explicit qualification is also used to
specify which one of a set of overloaded parameterless \vfunctions\v609. is  meant,
or to constrain a value to a given subtype.
4.8  \uAllocators\n
The evaluation of an allocator creates an \vobject\v303. and yields an \vaccess value\v330.
that \vdesignates\v330. the object.
    allocator ::=
       \unew\n \vsubtype_indication\v307. | \unew\n \vqualified_expression\v420.
The \vtype\v305. of the object created by an allocator is the base type of the type
mark given in either the subtype indication or  the  qualified  expression.
For  an  allocator with a qualified expression, this expression defines the
\vinitial value\v303. of the created object.  The type of the access value returned
by an allocator must be determinable solely from the context, but using the
fact that the value  returned  is  of  an  \vaccess  type\v330.  having  the  named
designated type.
The  only  allowed  forms  of  \vconstraint\v305.  in  the subtype indication of an
allocator are index and \vdiscriminant constraints\327..  If an allocator includes
a subtype indication and if the type of the object created is an \varray type\v321.
or a \vtype with discriminants\v305. that do not have default expressions, then the
subtype indication must either denote a constrained subtype, or include  an
explicit index or discriminant constraint.
If  the  type  of  the  created  object  is  an  array  type or a type with
discriminants, then the created  object  is  always  constrained.   If  the
allocator  includes a subtype indication, the created object is constrained
either by the subtype or  by  the  default  discriminant  values.   If  the
allocator   includes   a   qualified  expression,  the  created  object  is
constrained by the bounds or discriminants of the initial value.  For other
types, the subtype of the created object is  the  subtype  defined  by  the
subtype indication of the \vaccess type definition\v330..
For  the  evaluation  of  an  allocator,  the  \velaboration\v333.  of  the subtype
indication or the \vevaluation  of  the  qualified  expression\v420.  is  performed
first.  The new object is then created.  Initializations are then performed
as  for  a  declared  object (see 3.2.1);  the \vinitialization\v303. is considered
explicit in the case of a qualified expression;   any  initializations  are
implicit  in  the  case  of a subtype indication.  Finally, an access value
that designates the created object is returned.
An implementation must guarantee that any object created by the  evaluation
of  an allocator remains allocated for as long as this object or one of its
\vsubcomponents\v305. is accessible directly or indirectly, that is, as long as  it
can  be  denoted  by  some  name.   Moreover,  if  an  object or one of its
subcomponents belongs to a \vtask type\v902., it is considered to be accessible  as
long  as  the task is not terminated.  An implementation may (but need not)
reclaim the storage occupied by an object created  by  an  allocator,  once
this object has become inaccessible.
When  an  application  needs  closer  control  over  storage allocation for
objects designated by values  of  an  access  type,  such  control  may  be
achieved by one or more of the following means:
(a)  The total amount of storage available for the \vcollection\v330. of objects of
     an access type can be set by means of a \vlength clause\v1302. (see 13.2).
(b)  The  \vpragma\v210.  CONTROLLED  informs  the  implementation  that  automatic
     storage  reclamation  must  not be performed for objects designated by
     values of the access type, except upon  leaving  the  innermost  \vblock\v507.
     statement, \vsubprogram body\v603., or \vtask body\v901. that encloses the access type
     declaration, or after leaving the \vmain program\v1001..
        \upragma\n CONTROLLED (access_type_simple_name);
     A  pragma  CONTROLLED  for  a given access type is allowed at the same
     places as a \vrepresentation clause\v1301.  for  the  type  (see  13.1).   This
     pragma is not allowed for a \vderived type\v309..
(c)  The explicit deallocation of the object designated by an access  value
     can  be  achieved  by calling a \vprocedure\v600. obtained by \vinstantiation\v1206. of
     the predefined \vgeneric library procedure\v1201.  UNCHECKED_DEALLOCATION  (see
     13.10.1).
The  exception  \vSTORAGE_ERROR\v1101.  is  raised  by  an allocator if there is not
enough storage.  Note also  that  the  exception  CONSTRAINT_ERROR  can  be
raised by the evaluation of the qualified expression, by the elaboration of
the subtype indication, or by the initialization.
Examples (for access types declared in section 3.8):
 \unew\n CELL'(0, \unull\n, \unull\n)                          -- initialized explicitly
 \unew\n CELL'(VALUE => 0, SUCC => \unull\n, PRED => \unull\n) -- initialized explicitly
 \unew\n CELL                                          -- not initialized
 \unew\n MATRIX(1 .. 10, 1 .. 20)                  -- the bounds only are given
 \unew\n MATRIX'(1 .. 10 => (1 .. 20 => 0.0))      -- initialized explicitly
 \unew\n BUFFER(100)                          -- the discriminant only is given
 \unew\n BUFFER'(SIZE => 80, POS => 0, VALUE => (1 .. 80 => 'A'))
                                               -- initialized explicitly
4.9  \uStatic Expressions and Static Subtypes\n
Certain  \vexpressions\v410.  of  a  \vscalar type\v310. are said to be static.  Similarly,
certain \vdiscrete ranges\v321. are said to  be  static,  and  the  type  marks  of
certain scalar \vsubtypes\v305. are said to denote static subtypes.
An  expression  of  a scalar type is said to be static if and only if every
primary is one of those listed in (a) through  (h)  below,  every  operator
denotes  a  \vpredefined  operator\v411.,  and  the  evaluation  of  the expression
delivers a value (that is, it does not raise an \vexception\v1100.):
(a)  An \venumeration literal\v311. (including a \vcharacter literal\v207.).
(b)  A \vnumeric literal\v204..
(c)  A \vnamed number\v302..
(d)  A \vconstant\v303. explicitly declared by a \vconstant declaration\v303. with a static
     subtype, and \vinitialized\v303. with a static expression.
(e)  A \vfunction\v609. call whose function name is an operator symbol that denotes
     a predefined operator, including a function name that is  an  expanded
     name;  each \vactual parameter\v607. must also be a static expression.
(f)  A language-defined \vattribute\v405. of a static subtype;   for  an  attribute
     that  is  a  function,  the  actual  parameter  must  also be a static
     expression.
(g)  A \vqualified expression\v420. whose \vtype mark\v307. denotes a  static  subtype  and
     whose operand is a static expression.
(h)  A static expression enclosed in parentheses.
A  static  range  is a range whose bounds are static expressions.  A static
range constraint is a \vrange constraint\v310. whose range  is  static.   A  static
subtype is either a scalar \vbase type\v305., other than a \vgeneric formal type\v1203.;  or
a  scalar  subtype  formed  by imposing on a static subtype either a static
range constraint, or a floating  or  fixed  point  constraint  whose  range
constraint,  if any, is static.  A static discrete range is either a static
subtype or  a  static  range.   A  static  index  constraint  is  an  index
constraint  for which each index subtype of the corresponding array type is
static, and in which each discrete range is static.  A static  discriminant
constraint  is  a  discriminant  constraint  for  which the subtype of each
discriminant is static, and in which each expression is static.
\uNotes:\n
The accuracy of the evaluation of a static expression having a real type is
defined by the rules given in section 4.5.7.  If the result is not a  \vmodel\v316.
\vnumber\v316.  (or  a  \vsafe  number\v316.)  of  the  type,  the  value  obtained by this
evaluation at compilation time need not be the same as the value that would
be obtained by an evaluation at run time.
Array attributes are not static:  in particular, the RANGE attribute is not
static.
4.10  \uUniversal Expressions\n
A  universal_expression  is  either an expression that delivers a result of
type  \vuniversal_integer\v314.  or  one   that   delivers   a   result   of   type
universal_real.
The  same  \voperations  are predefined\v308. for the type universal_integer as for
any \vinteger  type\v314..   The  same  operations  are  predefined  for  the  type
universal_real  as  for  any  \vfloating  point  type\v319..   In  addition,  these
operations include the following multiplication and division operators:
Operator  Operation  Left operand       Right operand       Result type
                     type               type
   *      multiply   universal_real     universal_integer   universal_real
                     universal_integer  universal_real      universal_real
   /      divide     universal_real     universal_integer   universal_real
The  accuracy  of  the  \vevaluation  of  a  universal  expression\v411.  of   type
universal_real  is at least as good as that of the most accurate predefined
floating  point  type  supported  by   the   implementation,   apart   from
universal_real  itself.  Furthermore, if a universal expression is a static
expression, then the evaluation must be exact.
For the evaluation of an operation of a nonstatic universal expression,  an
implementation  is allowed to raise the exception NUMERIC_ERROR only if the
result of the operation is a real value whose absolute  value  exceeds  the
largest  \vsafe  number\v316.  of  the most accurate predefined floating point type
(excluding universal_real), or an integer value greater than \vSYSTEM.MAX_INT\v1308.
or less than \vSYSTEM.MIN_INT\v1308..
Note:
It is a consequence of the  above  rules  that  the  type  of  a  universal
expression   is   universal_integer  if  every  \vprimary\v410.  contained  in  the
expression is of this type (excluding \vactual parameters\v607. of \vattributes\v405.  that
are  \vfunctions\v609.,  and  excluding right operands of exponentiation operators)
and that otherwise the type is universal_real.
\uExamples:\n
    1 + 1       -- 2
    \uabs\n(-10)*3  -- 30
    KILO : \uconstant\n := 1000;
    MEGA : \uconstant\n := KILO*KILO;   -- 1_000_000
    LONG : \uconstant\n := FLOAT'DIGITS*2;
    HALF_PI    : \uconstant\n := PI/2;           -- see 3.2.2
    DEG_TO_RAD : \uconstant\n := HALF_PI/90;
    RAD_TO_DEG : \uconstant\n := 1.0/DEG_TO_RAD; -- equivalent to
                                                1.0/((3.14159_26536/2)/90)
5.       \uStatements\n
A  statement  defines  an  action  to be performed;  the process by which a
statement achieves its action is called execution of the statement.
This chapter describes the general  rules  applicable  to  all  statements.
Some  specific  statements are discussed in later chapters.  \vProcedure call\v606.
\vstatements\v606. are described in Chapter 6 on subprograms.  \vEntry  call\v905.,  \vdelay\v906.,
\vaccept\v905.,  \vselect\v907.,  and \vabort statements\v913. are described in Chapter 9 on tasks.
\vRaise statements\v1103. are described  in  Chapter  11  on  exceptions,  and  \vcode\v1312.
\vstatements\v1312.  in Chapter 13.  The remaining forms of statements are presented
in this chapter.
More details:
 5.1    \vSimple and Compound Statements - Sequences of Statements\v501.
 5.2    \vAssignment Statement\v502.
 5.3    \vIf Statements\v504.
 5.4    \vCase Statements\v505.
 5.5    \vLoop Statements\v506.
 5.6    \vBlock Statements\v507.
 5.7    \vExit Statements\v508.
 5.8    \vReturn Statements\v509.
 5.9    \vGoto Statements\v510.
5.1  \uSimple and Compound Statements - Sequences of Statements\n
A statement is either simple or compound.  A simple statement  encloses  no
other  statement.   A  compound statement can enclose simple statements and
other compound statements.
    sequence_of_statements ::= statement {statement}
    statement ::=
       {label} simple_statement | {label} compound_statement
    simple_statement ::= null_statement
       | \vassignment_statement\v502. | \vprocedure_call_statement\v606.
       | \vexit_statement\v508.       | \vreturn_statement\v509.
       | \vgoto_statement\v510.       | \ventry_call_statement\v905.
       | \vdelay_statement\v906.      | \vabort_statement\v913.
       | \vraise_statement\v1103.      | \vcode_statement\v1312.
    compound_statement ::=
         \vif_statement\v504.         | \vcase_statement\v505.
       | \vloop_statement\v506.       | \vblock_statement\v507.
       | \vaccept_statement\v905.     | \vselect_statement\v907.
    label ::= <<label_\vsimple_name\v401.>>
    null_statement ::= \unull\n;
A statement is said to be labeled by the label name of  any  label  of  the
statement.  A label name, and similarly a loop or \vblock name\v507., is implicitly
declared  at  the  end  of  the  declarative  part  of  the innermost block
statement, \vsubprogram body\v603., \vpackage body\v701., \vtask body\v901., or \vgeneric  body\v1201.  that
encloses  the  labeled  statement,  the  named loop statement, or the named
block statement, as the case may be.   For  a  block  statement  without  a
declarative  part,  an implicit \vdeclarative part\v333. (and preceding declare) is
assumed.
The \vimplicit declarations\v301. for different label names, \vloop names\v506., and  block
names  occur  in  the  same  order  as  the beginnings of the corresponding
labeled  statements,  loop  statements,  and  block  statements.   Distinct
\videntifiers\v203.  must  be  used  for  all label, loop, and block names that are
implicitly declared within the body of a  program  unit,  including  within
block statements enclosed by this body, but excluding within other enclosed
program  units  (a  program  unit is either a \vsubprogram\v600., a \vpackage\v700., a \vtask\v901.
\vunit\v901., or a \vgeneric unit\v1200.).
Execution of a null statement has no other effect than to pass to the  next
action.
The  execution of a sequence of statements consists of the execution of the
individual statements in succession until the sequence is completed,  or  a
transfer of control takes place.  A transfer of control is caused either by
the execution of an exit, return, or goto statement;  by the selection of a
\vterminate  alternative\v908.; by the \vraising of an exception\v1100.;  or (indirectly) by
the execution of an abort statement.
Examples of labeled statements:
    <<HERE>> <<ICI>> <<AQUI>> <<HIER>> \unull\n;
    <<AFTER>> X := 1;
Note:
The \vscope\v802. of a declaration starts at the place of  the  \vdeclaration\v301.  itself
(see  8.2).   In  the case of a label, loop, or block name, it follows from
this rule that the scope of the  implicit  declaration  starts  before  the
first  explicit occurrence of the corresponding name, since this occurrence
is either in a statement label, a loop statement, a block statement,  or  a
goto  statement.   An  implicit declaration in a block statement may hide a
declaration given in an outer \vprogram unit\v600. or block statement (according to
the usual rules of \vhiding\v803. explained in section 8.3).
5.2  \uAssignment Statement\n
An assignment statement replaces the current value of a \vvariable\v303. with a new
value specified by an \vexpression\v410..  The named variable  and  the  right-hand
side  expression must be of the same \vtype\v305.;  this type must not be a limited
type.
    assignment_statement ::=
       variable_name := expression;
For the execution of an assignment statement, the  variable  \vname\v401.  and  the
expression  are  first  evaluated, in some order that is not defined by the
language.  A check is then made that the value of the expression belongs to
the \vsubtype\v305. of the variable, except in the case of a variable  that  is  an
\varray\v321.  (the  assignment  then involves a \vsubtype conversion\v419. as described in
section 5.2.1).  Finally, the value of the expression becomes the new value
of the variable.
The \vexception CONSTRAINT_ERROR\v1101. is raised  if  the  above-mentioned  subtype
check  fails;   in  such  a  case the current value of the variable is left
unchanged.  If the variable is a \vsubcomponent\v305. that depends on \vdiscriminants\v326.
of an unconstrained record variable, then the execution of  the  assignment
is  \verroneous\v108. if the value of any of these discriminants is changed by this
execution.
\uExamples:\n
    VALUE := MAX_VALUE - 1;
    SHADE := BLUE;
    NEXT_FRAME(F)(M, N) := 2.5;        --  see 4.1.1
    U := DOT_PRODUCT(V, W);            --  see 6.5
    WRITER := (STATUS => OPEN, UNIT => PRINTER, LINE_COUNT => 60);
                                      --  see 3.7.3
    NEXT_CAR.\uall\n := (72074, \unull\n);    --  see 3.8.1
Examples of constraint checks:
    I, J : INTEGER \urange\n 1 .. 10;
    K    : INTEGER \urange\n 1 .. 20;
     ...
    I := J;  --  identical ranges
    K := J;  --  compatible ranges
    J := K;  --  will raise the exception CONSTRAINT_ERROR if K > 10
\uNotes:\n
The values of the discriminants of an \vobject\v302. designated by an access  value
cannot  be  changed  (not  even by assigning a complete value to the object
itself) since such objects, created by \vallocators\v421., are  always  constrained
(see 4.8);  however, subcomponents of such objects may be unconstrained.
If  the  right-hand  side  expression  is either a \vnumeric literal\v204. or named
number, or an attribute that yields a result of \vtype  universal_integer\v314.  or
\vuniversal_real\v316., then an \vimplicit type conversion\v419. is performed, as described
in section 4.6.
The  determination  of  the type of the variable of an assignment statement
may require consideration of the expression if the  variable  name  can  be
interpreted  as  the  name  of  a  variable  \vdesignated\v330. by the access value
returned by a \vfunction call\v606., and similarly, as a \vcomponent\v321. or \vslice\v403. of such
a variable (see section 8.7 for the context of \voverload\v610. resolution).
More details:
 5.2.1 \vArray Assigments\v503.
5.2.1  \uArray Assignments\n
If  the \vvariable\v303. of an \vassignment\v502. statement is an \varray\v321. variable (including
a \vslice\v403. variable), the value of the expression is implicitly  converted  to
the  subtype  of the array variable;  the result of this \vsubtype conversion\v419.
becomes the new value of the array variable.
This means that the new value of each component of the  array  variable  is
specified  by  the  \vmatching  component  in  the  array\v413.  value  obtained by
evaluation of the expression (see 4.5.2  for  the  definition  of  matching
components).   The subtype conversion checks that for each component of the
array variable there is a matching component in the array value,  and  vice
versa.   The  \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails;  in
such a case the value of each component  of  the  array  variable  is  left
unchanged.
\uExamples:\n
    A : STRING(1 .. 31);
    B : STRING(3 .. 33);
     ...
    A := B;  --  same number of components
    A(1 .. 9)  := "tar sauce";
    A(4 .. 12) := A(1 .. 9);  --  A(1 .. 12) = "tartar sauce"
\uNotes:\n
Array assignment is defined even in the case of overlapping slices, because
the  expression  on  the right-hand side is evaluated before performing any
component assignment.  In the above example, an implementation yielding A(1
.. 12) = "tartartartar" would be incorrect.
The implicit subtype conversion described above for assignment to an  array
variable  is performed only for the value of the right-hand side expression
as a whole;  it is not performed for subcomponents that are  array  values.
5.3  \uIf Statements\n
An if statement selects for execution one or none of the enclosed \vsequences\v501.
\vof  statements\v501., depending on the (truth) value of one or more corresponding
conditions.
    if_statement ::=
        \uif\n condition \uthen\n
          sequence_of_statements
       {\uelsif\n condition \uthen\n
          sequence_of_statements}
       [\uelse\n
          sequence_of_statements]
        \uend if\n;
    condition ::= boolean_expression
An \vexpression\v410. specifying a condition must be of a \vboolean type\v313..
For the execution of an if statement, the condition specified after if, and
any conditions specified after elsif, are evaluated in succession (treating
a final else as elsif TRUE then),  until  one  evaluates  to  TRUE  or  all
conditions  are  evaluated  and yield FALSE.  If one condition evaluates to
TRUE, then the corresponding sequence of statements is executed;  otherwise
none of the sequences of statements is executed.
\uExamples:\n
    \uif\n MONTH = DECEMBER \uand\n DAY = 31 \uthen\n
       MONTH := JANUARY;
       DAY   := 1;
       YEAR  := YEAR + 1;
    \uend if\n;
    \uif\n LINE_TOO_SHORT \uthen\n
       \uraise\n LAYOUT_ERROR;
    \uelsif\n LINE_FULL \uthen\n
       NEW_LINE;
       PUT(ITEM);
    \uelse\n
       PUT(ITEM);
    \uend if\n;
    \uif\n MY_CAR.OWNER.VEHICLE /= MY_CAR \uthen\n            --  see 3.8
       REPORT ("Incorrect data");
    \uend if\n;
5.4 \u Case Statements\n
A  case  statement  selects  for  execution  one of a number of alternative
\vsequences of statements\v501.;  the chosen alternative is defined by the value of
an \vexpression\v410..
    case_statement ::=
       \ucase\n expression \uis\n
           case_statement_alternative
          {case_statement_alternative}
       \uend case\n;
    case_statement_alternative ::=
       \uwhen\n \vchoice\v328. {| choice } =>
          sequence_of_statements
The expression must be of  a  \vdiscrete  type\v310.  which  must  be  determinable
independently  of the context in which the expression occurs, but using the
fact that the expression must be of a discrete \vtype\v305..  Moreover, the type of
this expression must not be a \vgeneric formal type\v1201..  Each choice in  a  case
statement alternative must be of the same type as the expression;  the list
of  choices specifies for which values of the expression the alternative is
chosen.
If the expression is the \vname\v401. of an \vobject\v303. whose \vsubtype\v305.  is  static,  then
each  value  of  this subtype must be represented once and only once in the
set of choices of the case statement, and no other value is allowed;   this
rule  is  likewise  applied  if the expression is a \vqualified expression\v420. or
\vtype conversion\v419. whose \vtype mark\v307. denotes a \vstatic subtype\v422..   Otherwise,  for
other  forms of expression, each value of the (\vbase\v305.) type of the expression
must be represented once and only once in the set of choices, and no  other
value is allowed.
The  simple  expressions  and  discrete  ranges  given as choices in a case
statement must be static.  A choice defined by a discrete range stands  for
all  values  in the corresponding range (none if a null range).  The choice
others is only allowed for the last alternative and as its only choice;  it
stands for all values (possibly none) not given in the choices of  previous
alternatives.  A component simple name is not allowed as a choice of a case
statement alternative.
The  execution  of  a  case  statement  consists  of  the evaluation of the
expression followed by the execution of the chosen sequence of  statements.
\uExamples:\n
    \ucase\n SENSOR \uis\n
       \uwhen\n ELEVATION  => RECORD_ELEVATION(SENSOR_VALUE);
       \uwhen\n AZIMUTH    => RECORD_AZIMUTH  (SENSOR_VALUE);
       \uwhen\n DISTANCE   => RECORD_DISTANCE (SENSOR_VALUE);
       \uwhen\n others     => \unull\n;
    \uend case\n;
    \ucase\n TODAY \uis\n
       \uwhen\n MON        => COMPUTE_INITIAL_BALANCE;
       \uwhen\n FRI        => COMPUTE_CLOSING_BALANCE;
       \uwhen\n TUE .. THU => GENERATE_REPORT(TODAY);
       \uwhen\n SAT .. SUN => \unull\n;
    \uend case\n;
    \ucase\n BIN_NUMBER(COUNT) \uis\n
       \uwhen\n 1      => UPDATE_BIN(1);
       \uwhen\n 2      => UPDATE_BIN(2);
       \uwhen\n 3 | 4  =>
          EMPTY_BIN(1);
          EMPTY_BIN(2);
       \uwhen others\n => raise ERROR;
    \uend case\n;
\uNotes:\n
The  execution  of  a  case statement chooses one and only one alternative,
since the choices are exhaustive and mutually exclusive.  Qualification  of
the expression of a case statement by a static subtype can often be used to
limit the number of choices that need be given explicitly.
An  others  choice  is  required  in  a  case statement if the  type of the
expression is the type universal_integer (for example, if the expression is
an integer literal), since this is the only way to cover all values of  the
type universal_integer.
5.5  \uLoop Statements\n
A  loop  statement includes a \vsequence of statements\v501. that is to be executed
repeatedly, zero or more times.
    loop_statement ::=
       [loop_simple_name:]
          [iteration_scheme] \uloop\n
             sequence_of_statements
           \uend loop\n [loop_simple_name];
    iteration_scheme ::= \uwhile\n condition
       | \ufor\n loop_parameter_specification
    loop_parameter_specification ::=
       identifier \uin\n [\ureverse\n] discrete_range
If a loop statement has a loop \vsimple name\v401., this simple name must be  given
both at the beginning and at the end.
A  loop  statement without an iteration scheme specifies repeated execution
of the sequence of statements.  Execution of the loop statement is complete
when the loop is left  as  a  consequence  of  the  execution  of  an  \vexit\v508.
\vstatement\v508., or as a consequence of some other transfer of control (see 5.1).
For  a  loop  statement  with  a  while  iteration scheme, the \vcondition\v504. is
evaluated before each execution of the  sequence  of  statements;   if  the
value  of the condition is \vTRUE\v313., the sequence of statements is executed, if
\vFALSE\v313. the execution of the loop statement is complete.
For a loop statement with  a  for  iteration  scheme,  the  loop  parameter
specification  is  the  \vdeclaration\v301.  of  the  loop parameter with the given
\videntifier\v203..  The loop parameter is an \vobject\v303. whose type is the \vbase type\v305. of
the \vdiscrete range\v322. (see 3.6.1).  Within the  sequence  of  statements,  the
loop parameter is a \vconstant\v303..  Hence a loop parameter is not allowed as the
(left-hand  side)  variable of an \vassignment statement\v502..  Similarly the loop
parameter must not be given as an out or in out parameter of a \vprocedure\v606. or
\ventry call statement\v905., or as an in out parameter of a \vgeneric instantiation\v1206..
For the execution of a loop statement with a for iteration scheme, the loop
parameter specification is first elaborated.  This \velaboration\v301. creates  the
loop parameter and evaluates the discrete range.
If  the discrete range is a \vnull range\v310., the execution of the loop statement
is complete.  Otherwise, the sequence of statements is  executed  once  for
each  value  of the discrete range (subject to the loop not being left as a
consequence of the execution of an exit statement or as  a  consequence  of
some  other  transfer  of  control).   Prior  to  each  such iteration, the
corresponding  value  of  the  discrete  range  is  assigned  to  the  loop
parameter.   These  values  are  assigned  in  increasing  order unless the
\vreserved word\v211. reverse is present, in which case the values are assigned  in
decreasing order.
Example of a loop statement without an iteration scheme:
    \uloop\n
       GET(CURRENT_CHARACTER);
       \uexit when\n CURRENT_CHARACTER = '*';
    \uend loop\n;
Example of a loop statement with a while iteration scheme:
    \uwhile\n BID(N).PRICE < CUT_OFF.PRICE \uloop\n
       RECORD_BID(BID(N).PRICE);
       N := N + 1;
    \uend loop\n;
Example of a loop statement with a for iteration scheme:
    \ufor\n J \uin\n BUFFER'RANGE \uloop\n     --  legal even with a null range
       \uif\n BUFFER(J) /= SPACE \uthen\n
          PUT(BUFFER(J));
       \uend if\n;
    \uend loop\n;
Example of a loop statement with a loop simple name:
    SUMMATION:
       \uwhile\n NEXT /= HEAD \uloop\n       -- see 3.8
          SUM  := SUM + NEXT.VALUE;
          NEXT := NEXT.SUCC;
       \uend loop\n SUMMATION;
\uNotes:\n
The \vscope\v802. of a loop parameter extends from the loop parameter specification
to  the end of the loop statement, and the \vvisibility\v803. rules are such that a
loop parameter is only visible within the sequence  of  statements  of  the
loop.
The  discrete  range  of  a  for  loop  is evaluated just once.  Use of the
reserved word reverse does not  alter  the  discrete  range,  so  that  the
following  iteration  schemes  are  not  equivalent;   the first has a null
range.
    \ufor\n J \uin reverse\n 1 ..  0
    \ufor\n J \uin\n 0 .. 1
Loop names are also used in exit statements, and in \vexpanded  names\v404.  (in  a
\vprefix\v401. of the loop parameter).
5.6  \uBlock Statements\n
A  block statement encloses a \vsequence of statements\v501. optionally preceded by
a \vdeclarative part\v333. and optionally followed by \vexception handlers\v1102..
    block_statement ::=
       [block_simple_name:]
          [\udeclare\n
               declarative_part]
           \ubegin\n
               sequence_of_statements
          [\uexception\n
               exception_handler
              {exception_handler}]
           \uend\n [block_simple_name];
If a block statement has a block \vsimple name\v401.,  this  simple  name  must  be
given both at the beginning and at the end.
The  execution  of  a  block  statement  consists of the elaboration of its
declarative part (if any) followed by the  execution  of  the  sequence  of
statements.   If  the block statement has exception handlers, these service
corresponding exceptions that  are  raised  during  the  execution  of  the
sequence of statements (see 11.2).
Example:
    SWAP:
       \udeclare\n
          TEMP : INTEGER;
       \ubegin\n
          TEMP := V; V := U; U := TEMP;
       \uend\n SWAP;
\uNotes:\n
If  \vtask  objects\v902.  are declared within a block statement whose execution is
completed, the block statement is not left until all  its  \vdependent  tasks\v904.
are terminated (see 9.4).  This rule applies also to a completion caused by
an \vexit\v508., \vreturn\v509., or \vgoto statement\v510.;  or by the \vraising of an exception\v1100..
Within  a  block  statement,  the  block name can be used in \vexpanded names\v404.
denoting local entities such as SWAP.TEMP in the above example  (see  4.1.3
(f)).
5.7  \uExit Statements\n
An exit statement is used to complete the execution of  an  enclosing  \vloop\v506.
\vstatement\v506. (called the loop in what follows);  the completion is conditional
if the exit statement includes a \vcondition\v504..
    exit_statement ::=
       \uexit\n [loop_name] [\uwhen\n condition];
An  exit  statement with a \vloop name\v506. is only allowed within the named loop,
and applies to that loop;  an exit statement without a loop  name  is  only
allowed within a loop, and applies to the innermost enclosing loop (whether
named or not).  Furthermore, an exit statement that applies to a given loop
must  not appear within a \vsubprogram body\v603., \vpackage body\v701., task body, \vgeneric\v1201.
\vbody\v1201., or \vaccept statement\v905., if this construct  is  itself  enclosed  by  the
given loop.
For the execution of an exit statement, the condition, if present, is first
evaluated.   Exit from the loop then takes place if the value is \vTRUE\v313. or if
there is no condition.
\uExamples:\n
    \ufor\n N \uin\n 1 .. MAX_NUM_ITEMS \uloop\n
       GET_NEW_ITEM(NEW_ITEM);
       MERGE_ITEM(NEW_ITEM, STORAGE_FILE);
       \uexit when\n NEW_ITEM = TERMINAL_ITEM;
    \uend loop\n;
    MAIN_CYCLE:
       \uloop\n
          --  initial statements
          \uexit\n MAIN_CYCLE \uwhen\n FOUND;
          --  final statements
       \uend loop\n MAIN_CYCLE;
Note:
Several nested loops can be exited by an  exit  statement  that  names  the
outer loop.
5.8  \uReturn Statements\n
A  return  statement  is  used  to  complete the execution of the innermost
enclosing function, procedure, or \vaccept statement\v905..
    return_statement ::= \ureturn\n [expression];
A return statement is only allowed within  the  body  of  a  \vsubprogram\v603.  or
generic  subprogram,  or  within  an  accept  statement, and applies to the
innermost (enclosing) such construct;  a return statement  is  not  allowed
within  the  body  of a \vtask unit\v901.,  \vpackage\v701., or generic package enclosed by
this construct (on  the  other  hand,  it  is  allowed  within  a  compound
statement  enclosed  by  this  construct  and,  in  particular,  in a \vblock\v507.
\vstatement\v507.).
A return statement for an accept statement or for the body of  a  \vprocedure\v603.
or  generic  procedure  must not include an \vexpression\v410..  A return statement
for the body of a \vfunction\v603. or generic function must include an  expression.
The  value  of  the expression defines the result returned by the function.
The type of this expression must be the base type of the  \vtype  mark\v307.  given
after  the  \vreserved  word\v211.  return  in the specification of the function or
generic function (this type mark defines the \vresult subtype\v601.).
For the execution of a return statement, the expression (if any)  is  first
evaluated and a check is made that the value belongs to the result \vsubtype\v305..
The  execution  of  the  return statement is thereby completed if the check
succeeds;  so also is the execution of the  subprogram  or  of  the  accept
statement.   The  \vexception  CONSTRAINT_ERROR\v1101. is raised at the place of the
return statement if the check fails.
\uExamples:\n
    \ureturn\n;                         -- in a procedure
    \ureturn\n KEY_VALUE(LAST_INDEX);   -- in a function
Note:
If the expression is either a  \vnumeric  literal\v204.  or  \vnamed  number\v302.,  or  an
\vattribute\v1500. that yields a result of \vtype universal_integer\v314. or \vuniversal_real\v316.,
then  an  \vimplicit  conversion\v419.  of  the result is performed as described in
section 4.6.
5.9  \uGoto Statements\n
A goto statement specifies  an  explicit  \vtransfer  of  control\v501.  from  this
\vstatement\v501. to a target statement named by a \vlabel\v501..
    goto_statement ::= \ugoto\n label_name;
The  innermost  \vsequence  of  statements\v501. that encloses the target statement
must also enclose the goto statement (note that the goto statement can be a
statement of an inner sequence).   Furthermore,  if  a  goto  statement  is
enclosed  by  an  \vaccept  statement\v905. or the body of a \vprogram unit\v600., then the
target statement must not be outside this enclosing construct;  conversely,
it follows from the previous rule that if the target statement is  enclosed
by such a construct, then the goto statement cannot be outside.
The  execution  of  a  goto statement transfers control to the named target
statement.
Note:
The above rules allow transfer of control to a statement  of  an  enclosing
sequence  of  statements  but  not  the  reverse.  Similarly, they prohibit
transfers of control such as between alternatives of a \vcase  statement\v505.,  \vif\v504.
\vstatement\v504.,  or  \vselect  statement\v907.;  between \vexception handlers\v1102.;  or from an
exception handler of a \vframe\v1102. back to the sequence  of  statements  of  this
frame.
Example:
    <<COMPARE>>
       \uif\n A(I) < ELEMENT \uthen\n
          \uif\n LEFT(I) /= 0 \uthen\n
             I := LEFT(I);
             \ugoto\n COMPARE;
          \uend if\n;
          --  some statements
       \uend if\n;
6.       \uSubprograms\n
Subprograms  are  one  of the four forms of program unit, of which programs
can be composed.  The other forms are \vpackages\v700.,  \vtask  units\v900.,  and \vgeneric\v1200.
\vunits\v1200..
A  subprogram  is a program unit whose execution is invoked by a \vsubprogram\v606.
\vcall\v606..  There are two forms of  subprogram:  \vprocedures\v601.  and  \vfunctions\v609..   A
\vprocedure  call\v606.  is  a  statement;   a  \vfunction  call\v606. is an expression and
returns a value.  The definition of a subprogram can be given in two parts:
a \vsubprogram declaration\v601. defining its calling conventions, and a \vsubprogram\v603.
\vbody\v603. defining its execution.
More details:
 6.1    \vSubprogram Declarations\v601.
 6.2    \vFormal Parameter Modes\v602.
 6.3    \vSubprogram Bodies\v603.
 6.4    \vSubprogram Calls\v606.
 6.5    \vFunction Subprograms\v609.
 6.6    \vParameter and Result Type Profile - Overloading of Subprograms\v610.
 6.7    \vOverloading of Operators\v611.
6.1  \uSubprogram Declarations\n
A subprogram \vdeclaration\v301. declares a \vprocedure\v600. or a \vfunction\v609.,  as  indicated
by the initial reserved word.
    subprogram_declaration ::= subprogram_specification;
    subprogram_specification ::=
         procedure identifier [formal_part]
       | function designator  [formal_part] \ureturn\n \vtype_mark\v307.
    designator ::= identifier | operator_symbol
    operator_symbol ::= \vstring_literal\v208.
    formal_part ::=
       (parameter_specification {; parameter_specification})
    parameter_specification ::=
       \videntifier_list\v302. : mode type_mark [:= expression]
    mode ::= [\uin\n] | \uin out\n | \uout\n
The  specification  of  a procedure specifies its \videntifier\v203. and its \vformal\v602.
\vparameters\v602. (if  any).   The  specification  of  a  function  specifies  its
designator,  its formal parameters (if any) and the subtype of the returned
value (the result subtype).  A designator that is  an  \voperator\v411.  symbol  is
used  for  the  \voverloading\v610.  of  an  operator.   The sequence of characters
represented by an operator symbol must be an operator belonging to  one  of
the  six  classes  of  overloadable operators defined in section 4.5 (extra
spaces are not allowed and the case of letters is not significant).
A parameter specification with  several  identifiers  is  equivalent  to  a
sequence  of  single parameter specifications, as explained in section 3.2.
Each single parameter specification declares a  formal  parameter.   If  no
\vmode\v602.  is  explicitly  given,  the  mode  in  is  assumed.   If  a parameter
specification ends with  an  \vexpression\v410.,  the  expression  is  the  default
expression  of  the formal parameter.  A default expression is only allowed
in a parameter specification if the  mode  is  in  (whether  this  mode  is
indicated explicitly or implicitly).  The type of a default expression must
be that of the corresponding formal parameter.
The use of a \vname\v401. that denotes a formal parameter is not allowed in default
expressions  of  a  formal  part  if  the specification of the parameter is
itself given in this formal part.
The \velaboration\v333. of a subprogram declaration  elaborates  the  corresponding
formal part.  The \velaboration of a formal part has no other effect\v333..
Examples of subprogram declarations:
    \uprocedure\n TRAVERSE_TREE;
    \uprocedure\n INCREMENT(X : \uin out\n INTEGER);
    \uprocedure\n RIGHT_INDENT(MARGIN : \uout\n LINE_SIZE);          --  see 3.5.4
    \uprocedure\n SWITCH(FROM, TO : \uin out\n LINK);                --  see 3.8.1
    \ufunction\n RANDOM \ureturn\n PROBABILITY;                      --  see 3.5.7
    \ufunction\n MIN_CELL(X : LINK) \ureturn\n CELL;                 --  see 3.8.1
    \ufunction\n NEXT_FRAME(K : POSITIVE) \ureturn\n FRAME;          --  see 3.8
    \ufunction\n DOT_PRODUCT(LEFT,RIGHT: VECTOR) \ureturn\n REAL;    --  see 3.6
    \ufunction\n "*"(LEFT,RIGHT : MATRIX) \ureturn\n MATRIX;         --  see 3.6
Examples of in parameters with default expressions:
 \uprocedure\n PRINT_HEADER(PAGES  : \uin\n NATURAL;
                HEADER : \uin\n LINE    :=  (1 .. LINE'LAST => ' '); -- see 3.6
                CENTER : \uin\n BOOLEAN := TRUE);
\uNotes:\n
The  \vevaluation\v411.  of  default  expressions  is  caused by certain \vsubprogram\v606.
\vcalls\v606., as described in section 6.4.2 (default expressions are not evaluated
during the elaboration of the subprogram declaration).
All subprograms can be called recursively and are reentrant.
6.2  \uFormal Parameter Modes\n
The value of an \vobject\v302. is said to be read when this value is \vevaluated\v411.;  it
is  also  said to be read when one of its \vsubcomponents\v305. is read.  The value
of a \vvariable\v303. is said to be updated when an \vassignment\v502. is performed to  the
variable,  and  also  (indirectly)  when  the  variable  is  used as \vactual\v607.
\vparameter\v607. of a \vsubprogram call\v606. or \ventry call  statement\v905.  that  updates  its
value;   it  is  also  said  to be updated when one of its subcomponents is
updated.
A \vformal parameter\v601. of a subprogram has one of the three following \vmodes\v601.:
 \uin\n       The formal parameter  is a  constant  and  permits   only reading
          of the value  of the associated actual parameter.
 \uin out\n   The  formal parameter is a variable  and permits both reading and
          updating of the  value of the associated actual parameter.
 \uout\n      The  formal  parameter is a variable  and permits updating of the
          value of the associated actual parameter.
          The value  of  a scalar parameter that is not updated by the call
          is undefined  upon return;  the  same  holds for the  value  of a
          scalar subcomponent,  other  than a  \vdiscriminant\v326..   Reading  the
          bounds and discriminants  of the  formal  parameter  and  of  its
          subcomponents is allowed,  but no other reading.
For a scalar parameter, the above effects are achieved  by  copy:   at  the
start  of  each  call, if the mode is in or in out, the value of the actual
parameter is copied into  the  associated  formal  parameter;   then  after
normal completion of the \vsubprogram body\v603., if the mode is in out or out, the
value  of  the  formal  parameter is copied back into the associated actual
parameter.  For a parameter whose type is an \vaccess type\v330., copy-in  is  used
for all three modes, and copy-back for the modes in out and out.
For  a  parameter  whose  type  is  an  \varray\v321.,  \vrecord\v325.,  or  \vtask type\v902., an
implementation may likewise achieve the  above  effects  by  copy,  as  for
\vscalar  types\v310..   In  addition, if copy is used for a parameter of mode out,
then copy-in is required at least for the bounds and discriminants  of  the
actual  parameter  and of its subcomponents, and also for each subcomponent
whose type is an access type.  Alternatively, an implementation may achieve
these effects by reference, that is, by arranging that  every  use  of  the
formal  parameter  (to  read or to update its value) be treated as a use of
the associated actual parameter, throughout the execution of the subprogram
call.  The language does not define which of these two mechanisms is to  be
adopted  for  parameter  passing,  nor  whether different calls to the same
subprogram are to use the same mechanism.  The execution of  a  program  is
\verroneous\v108.  if  its  effect  depends  on  which mechanism is selected by the
implementation.
For a parameter whose type  is  a  \vprivate  type\v704.,  the  above  effects  are
achieved  according to the rule that applies to the corresponding full type
declaration.
Within the body of a subprogram, a  formal  parameter  is  subject  to  any
\vconstraint\v305.   resulting   from   the   \vtype  mark\v307.  given  in  its  \vparameter\v601.
\vspecification\v601..  For a formal parameter of an \vunconstrained array type\v321.,  the
bounds  are obtained from the actual parameter, and the formal parameter is
constrained by these \vbounds (see 3.6.1)\v322..   For  a  formal  parameter  whose
declaration  specifies  an  \vunconstrained  (private  or  record)  type with\v326.
\vdiscriminants\v326., the discriminants of the formal  parameter  are  initialized
with the values of the corresponding discriminants of the actual parameter;
the  formal parameter is unconstrained if and only if the mode is in out or
out and the variable  name  given  for  the  actual  parameter  denotes  an
\vunconstrained variable\v303. (see 3.7.1 and 6.4.1).
If the actual parameter of a subprogram call is a subcomponent that \vdepends\v326.
\von discriminants\v326. of an unconstrained record variable, then the execution of
the  call  is  erroneous  if  the  value of any of the discriminants of the
variable is changed by this execution;  this rule does  not  apply  if  the
mode  is  in and the type of the subcomponent is a scalar type or an access
type.
\uNotes:\n
For parameters of array and record types, the parameter passing rules  have
these consequences:
  -  If the execution of a subprogram  is  abandoned  as  a  result  of  an
     \vexception\v1100.,  the  final value of an actual parameter of such a type can
     be either its value before the call or a value assigned to the  formal
     parameter during the execution of the subprogram.
  -  If no actual parameter of such a type is accessible by more  than  one
     path,  then  the effect of a subprogram call (unless abandoned) is the
     same whether or not the  implementation  uses  copying  for  parameter
     passing.   If,  however,  there  are  multiple  access paths to such a
     parameter (for example,  if  a  \vglobal\v801.  variable,  or  another  formal
     parameter, refers to the same actual parameter), then the value of the
     formal  is  undefined after updating the actual other than by updating
     the formal.  A program using such an undefined value is erroneous.
The same parameter modes are defined for formal parameters of entries  (see
9.5)  with  the same meaning as for subprograms.  Different parameter modes
are defined for \vgeneric formal parameters\v1201..
For all modes, if an actual parameter designates  a  \vtask\v900.,  the  associated
formal   parameter  designates  the  same  task;   the  same  holds  for  a
subcomponent of an actual parameter and the corresponding  subcomponent  of
the associated formal parameter.
6.3  \uSubprogram Bodies\n
A \vsubprogram\v600. body specifies the execution of a subprogram.
    subprogram_body ::=
        subprogram_specification \uis\n
           [declarative_part]
        \ubegin\n
            sequence_of_statements
       [\uexception\n
            exception_handler
           {exception_handler}]
        \uend\n [designator];
The  \vdeclaration\v301.  of  a  subprogram  is optional.  In the absence of such a
declaration, the \vsubprogram specification\v601. of the subprogram body  (or  \vbody\v1004.
\vstub\v1004.) acts as the declaration.  For each \vsubprogram declaration\v601., there must
be  a  corresponding  body  (except  for  a  subprogram  written in another
language, as explained in section 13.9).  If both a declaration and a  body
are  given,  the  subprogram  specification of the body must \vconform\v604. to the
subprogram  specification  of  the  declaration  (see  section  6.3.1   for
conformance rules).
If a \vdesignator\v601. appears at the end of a subprogram body, it must repeat the
designator of the subprogram specification.
The  \velaboration\v333. of a subprogram body has no other effect than to establish
that the body can from then on be used for the execution of  calls  of  the
subprogram.
The  execution  of  a  subprogram  body is  invoked by  a  \vsubprogram call\v606..
For  this   execution,   after   establishing   the   association   between
\vformal  parameters\v601.  and \vactual parameters\v607., the \vdeclarative part\v333. of the body
is elaborated, and the \vsequence of statements\v501. of the body is then executed.
Upon completion of the body,   return  is  made  to  the  caller  (and  any
necessary  copying  back  of formal to actual parameters occurs (see 6.2)).
The optional \vexception handlers\v1102. at the end  of  a  subprogram  body  handle
\vexceptions\v1100. raised during the execution of the sequence of statements of the
subprogram body (see 11.4).
Note:
It  follows  from  the  \vvisibility\v803. rules that if a subprogram declared in a
\vpackage\v700. is to be visible outside the package,  a  subprogram  specification
must  be  given in the \vvisible part\v702. of the package.  The same rules dictate
that a subprogram declaration must be given if a  call  of  the  subprogram
occurs  textually  before  the  subprogram  body (the declaration must then
occur earlier than the call in the  program  text).   The  rules  given  in
sections   3.9  and  7.1  imply  that  a  subprogram  declaration  and  the
corresponding body must both \voccur immediately\v801. \vwithin\v801. the same  \vdeclarative\v801.
\vregion\v801..
Example of subprogram body:
    \uprocedure\n PUSH(E : \uin\n ELEMENT_TYPE; S : \uin out\n STACK) \uis\n
    \ubegin\n
       \uif\n S.INDEX = S.SIZE \uthen\n
          \uraise\n STACK_OVERFLOW;
       \uelse\n
          S.INDEX := S.INDEX + 1;
          S.SPACE(S.INDEX) := E;
       \uend if\n;
    \uend\n PUSH;
More details:
 6.3.1  \vConformance Rules\v604.
 6.3.2  \vInline Expansion of Subprograms\v605.
6.3.1  \uConformance Rules\n
Whenever the language rules require or \vallow\v108. the specification of  a  given
subprogram  to be provided in more than one place, the following variations
are allowed at each place:
  -  A \vnumeric literal\v204. can be replaced by a different  numeric  literal  if
     and only if both have the same value.
  -  A \vsimple name\v401. can be replaced by an \vexpanded name\v404. in which this simple
     \vname\v401. is the \vselector\v404., if and only if at both places the meaning of the
     simple name is given by the same \vdeclaration\v301..
  -  A string literal given as an \voperator symbol\v601.  can  be  replaced  by  a
     different  string  literal  if  and  only  if  both represent the same
     operator.
Two \vsubprogram specifications\v601. are said to conform if, apart  from  \vcomments\v209.
and  the  above  allowed  variations, both specifications are formed by the
same sequence of \vlexical elements\v200., and corresponding lexical  elements  are
given the same meaning by the \vvisibility\v803. and \voverloading\v610. rules.
Conformance  is  likewise defined for \vformal parts\v601., \vdiscriminant parts\v326., and
type marks (for \vdeferred constants\v707. and for \vactual parameters\v606. that have  the
form of a \vtype conversion\v419. (see 6.4.1)).
\uNotes:\n
A  simple  name can be replaced by an expanded name even if the simple name
is itself the \vprefix\v401. of a \vselected component\v404..   For  example,  Q.R  can  be
replaced by P.Q.R if Q is declared immediately within P.
The  following  specifications  do not conform since they are not formed by
the same sequence of lexical elements:
    \uprocedure\n P(X,Y : INTEGER)
    \uprocedure\n P(X : INTEGER; Y : INTEGER)
    \uprocedure\n P(X,Y : \uin\n INTEGER)
6.3.2  \uInline Expansion of Subprograms\n
The  \vpragma\v210.  INLINE  is  used  to  indicate  that  inline  expansion of the
\vsubprogram body\v603. is desired for every call of each of the named \vsubprograms\v600..
The form of this pragma is as follows:
    \upragma\n INLINE (name {, name});
Each \vname\v401. is either the name of a subprogram  or  the  name  of  a  \vgeneric\v1201.
\vsubprogram\v1201..   The  pragma  INLINE  is  only  \vallowed\v108.  at  the  place  of  a
\vdeclarative item\v333. in a \vdeclarative part\v333. or \vpackage specification\v701., or after a
\vlibrary unit\v1001. in a \vcompilation\v1001., but before any subsequent \vcompilation\v1001.  \vunit\v1001..
If  the  pragma  appears at the place of a declarative item, each name must
denote a  subprogram  or  a  generic  subprogram  declared  by  an  earlier
declarative item of the same declarative part or package specification.  If
several  (\voverloaded\v610.)  subprograms  satisfy  this  requirement,  the pragma
applies to all of them.  If the pragma appears after a given library  unit,
the  only  name allowed is the name of this unit.  If the name of a generic
subprogram is mentioned in the pragma, this indicates that inline expansion
is desired for calls of all subprograms obtained by  \vinstantiation\v1206.  of  the
named \vgeneric unit\v1200..
The  meaning of a subprogram is not changed by the pragma INLINE.  For each
call of the named subprograms, an implementation is free to  follow  or  to
ignore  the  recommendation expressed by the pragma.  (Note, in particular,
that the recommendation  cannot  generally  be  followed  for  a  recursive
subprogram.)
6.4  \uSubprogram Calls\n
A  \vsubprogram\v600. call is either a procedure call statement or a function call;
it invokes the execution of the corresponding subprogram  body.   The  call
specifies  the  association  of  the actual parameters, if any, with \vformal\v601.
\vparameters\v601. of the subprogram.
    procedure_call_statement ::=
        procedure_name [actual_parameter_part];
    function_call ::=
        function_name [actual_parameter_part]
    actual_parameter_part ::=
        (parameter_association {, parameter_association})
    parameter_association ::=
       [formal_parameter =>] actual_parameter
    formal_parameter ::= parameter_simple_name
    actual_parameter ::=
       \vexpression\v410. | \vvariable_name\v303. | \vtype_mark\v307.(variable_name)
Each  parameter  association  associates  an  actual   parameter   with   a
corresponding  formal  parameter.   A  parameter  association is said to be
named if the formal parameter is named explicitly;  it is otherwise said to
be  positional.   For  a  positional  association,  the  actual   parameter
corresponds  to  the  formal parameter with the same position in the \vformal\v601.
\vpart\v601..
Named associations can be given in any order, but if  both  positional  and
named  associations are used in the same call, positional associations must
occur first, at their normal position.  Hence once a named  association  is
used, the rest of the call must use only named associations.
For  each  formal parameter of a subprogram, a subprogram call must specify
exactly one corresponding  actual  parameter.   This  actual  parameter  is
specified either explicitly, by a parameter association, or, in the absence
of such an association, by a \vdefault expression\v601. (see 6.4.2).
The parameter associations of a subprogram call are evaluated in some order
that  is not defined by the language.  Similarly, the language rules do not
define in which order the values of in out or  out  parameters  are  copied
back into the corresponding actual parameters (when this is done).
Examples of procedure calls:
  TRAVERSE_TREE;                                               --  see 6.1
  TABLE_MANAGER.INSERT(E);                                     --  see 7.5
  PRINT_HEADER(128, TITLE, TRUE);                              --  see 6.1
  SWITCH(FROM => X, TO => NEXT);                               --  see 6.1
  PRINT_HEADER(128, HEADER => TITLE, CENTER => TRUE            --  see 6.1
  PRINT_HEADER(HEADER => TITLE, CENTER => TRUE, PAGES => 128); --  see 6.1
Examples of function calls:
    DOT_PRODUCT(U, V)   --  see 6.1 and 6.5
    CLOCK               --  see 9.6
More details:
 6.4.1  \vParameter Associations\v607.
 6.4.2  \vDefault Parameters\v608.
6.4.1  \uParameter Associations\n
Each  \vactual  parameter\v606. must have the same \vtype\v305. as the corresponding \vformal\v601.
\vparameter\v601..
An actual \vparameter associated\v606. with a formal parameter of \vmode\v601. in  must  be
an \vexpression\v410.;  it is evaluated before the call.
An  actual  parameter  associated with a formal parameter of mode in out or
out must be either the \vname\v401. of a  \vvariable\v303.,  or  of  the  form  of  a  \vtype\v419.
\vconversion\v419.  whose  argument is the name of a variable.  In either case, for
the mode in out, the variable must not be a formal parameter of mode out or
a subcomponent thereof.  For an actual parameter that has  the  form  of  a
type conversion, the \vtype mark\v307. must \vconform\v604. to the type mark of
he formal parameter;  the allowed operand and target types are the same as
for type conversions (see 4.6).
The  variable  name  given for an actual parameter of mode in out or out is
evaluated before the call.  If the actual parameter has the form of a  type
conversion,  then  before  the  call,  for  a parameter of mode in out, the
variable is converted to the specified type;  after (normal) completion  of
the  subprogram  body,  for  a  parameter of mode in out or out, the formal
parameter is converted back  to  the  type  of  the  variable.   (The  type
specified in the conversion must be that of the formal parameter.)
The  following \vconstraint\v305. checks are performed for parameters of scalar and
access types:
  -  Before the call:  for a parameter of mode in or in out, it is  checked
     that  the  value of the actual parameter belongs to the \vsubtype\v305. of the
    formal parameter.
  -  After (normal) completion of the subprogram body:  for a parameter  of
     mode  in  out  or  out,  it  is  checked  that the value of the formal
     parameter belongs to the subtype of the actual variable.  In the  case
     of  a  type conversion, the value of the formal parameter is converted
     back and the check applies to the result of the conversion.
In each of the above cases, the execution of the program  is  \verroneous\v108.  if
the checked \vvalue is undefined\v303..
For  other  types,  for  all  modes, a check is made before the call as for
scalar and access types;  no check is made upon return.
The \vexception CONSTRAINT_ERROR\v1101. is raised at the  place  of  the  subprogram
call if either of these checks fails.
Note:
For \varray types\v321. and for types with \vdiscriminants\v326., the check before the call
is  sufficient (a check upon return would be redundant) if the type mark of
the formal parameter denotes a \vconstrained  subtype\v305.,  since  neither  \varray\v321.
\vbounds\v321. nor discriminants can then vary.
If this type mark denotes an \vunconstrained array type\v321., the formal parameter
is constrained with the bounds of the corresponding actual parameter and no
check  (neither  before  the  call  nor upon return) is needed (see 3.6.1).
Similarly, no check is needed if the type  mark  denotes  an  \vunconstrained\v326.
\vtype  with  discriminants\v326.,  since  the formal parameter is then constrained
exactly as the corresponding actual parameter (see 3.7.1).
6.4.2  \uDefault Parameters\n
If a \vparameter specification\v601. includes a default expression for a  parameter
of  \vmode\v601.  in,  then  corresponding  \vsubprogram  calls\v606.  need  not  include a
\vparameter association\v606. for the parameter.  If  a  parameter  association  is
thus  omitted from a call, then the rest of the call, following any initial
\vpositional associations\v606., must use only \vnamed associations\v606..
For any omitted parameter association, the default expression is  evaluated
before  the  call  and  the  resulting  value is used as an implicit \vactual\v607.
\vparameter\v607..
Examples of procedures with default values:
    \uprocedure\n ACTIVATE(PROCESS : \uin\n PROCESS_NAME;
                       AFTER   : \uin\n PROCESS_NAME := NO_PROCESS;
                       WAIT    : \uin\n DURATION := 0.0;
                       PRIOR   : \uin\n BOOLEAN := FALSE);
    \uprocedure\n PAIR(LEFT, RIGHT : PERSON_NAME := \unew\n PERSON);
Examples of their calls:
    ACTIVATE(X);
    ACTIVATE(X, AFTER => Y);
    ACTIVATE(X, WAIT => 60.0, PRIOR => TRUE);
    ACTIVATE(X, Y, 10.0, FALSE);
    PAIR;
    PAIR(LEFT => \unew\n PERSON, RIGHT => \unew\n PERSON);
Note:
If a default expression is used for two or more parameters  in  a  multiple
parameter  specification, the default expression is evaluated once for each
omitted parameter.  Hence in the above examples, the two calls of PAIR  are
equivalent.
6.5  \uFunction Subprograms\n
A \vfunction\v601. is a subprogram that returns a value (the result of the \vfunction\v606.
\vcall\v606.).   The  \vspecification  of  a  function\v601.  starts with the reserved word
function, and the parameters, if any, must have the \vmode\v601. in  (whether  this
mode  is  specified  explicitly  or  implicitly).   The  \vstatements\v500.  of the
\vfunction body\v603. (excluding statements of program units that are inner to  the
function  body)  must  include one or more \vreturn statements\v509. specifying the
returned value.
The \vexception PROGRAM_ERROR\v1101. is raised if a function body is left  otherwise
than  by  a  return statement.  This does not apply if the execution of the
function is abandoned as a result of an \vexception\v1100..
Example:
    \ufunction\n DOT_PRODUCT(LEFT, RIGHT : VECTOR) \ureturn\n REAL \uis\n
       SUM : REAL := 0.0;
    \ubegin\n
       CHECK(LEFT'FIRST = RIGHT'FIRST \uand\n LEFT'LAST = RIGHT'LAST);
       \ufor\n J \uin\n LEFT'RANGE \uloop\n
          SUM := SUM + LEFT(J)*RIGHT(J);
       \uend loop\n;
       \ureturn\n SUM;
    \uend\n DOT_PRODUCT;
6.6  \uParameter and Result Type Profile - Overloading of Subprograms\n
Two  formal  parts  are said to have the same parameter type profile if and
only if they have the same number of  parameters,  and  at  each  parameter
position corresponding parameters have the same \vbase type\v305..  A \vsubprogram\v600. or
\ventry\v905.  has the same parameter and result \vtype\v305. profile as another subprogram
or entry if and only if both have the  same  parameter  type  profile,  and
either both are \vfunctions\v609. with the same result base type, or neither of the
two is a function.
The  same  subprogram  identifier or \voperator symbol\v601. can be used in several
\vsubprogram specifications\v601..  The \videntifier\v203. or operator symbol is then  said
to  be  \voverloaded\v807.;   the subprograms that have this identifier or operator
symbol are also said to be overloaded  and  to  overload  each  other.   As
explained  in  section  8.3, if two subprograms overload each other, one of
them can hide the other only if both subprograms have  the  same  parameter
and  result  type  profile (see section 8.3 for the other requirements that
must be met for \vhiding\v803.).
A call to an overloaded subprogram is ambiguous (and therefore \villegal\v108.)  if
the  name  of  the  subprogram,  the  number of \vparameter associations\v606., the
types and the order of the \vactual  parameters\v607.,  the  names  of  the  \vformal\v601.
\vparameters\v601.  (if  named  associations  are  used),  and the result type (for
functions)  are  not  sufficient  to  determine  exactly  one  (overloaded)
subprogram specification.
Examples of overloaded subprograms:
    \uprocedure\n PUT(X : INTEGER);
    \uprocedure\n PUT(X : STRING);
    \uprocedure\n SET(TINT   : COLOR);
    \uprocedure\n SET(SIGNAL : LIGHT);
Examples of calls:
    PUT(28);
    PUT("no possible ambiguity here");
    SET(TINT   => RED);
    SET(SIGNAL => RED);
    SET(COLOR'(RED));
    --  SET(RED) would be ambiguous since RED may
    --  denote a value either of type COLOR or of type LIGHT
\uNotes:\n
The  notion of parameter and result type profile does not include parameter
names, parameter modes, parameter subtypes, default expressions  and  their
presence or absence.
Ambiguities  may (but need not) arise when actual parameters of the call of
an  overloaded  subprogram  are  themselves  overloaded   \vfunction   calls\v606.,
\vliterals\v406.,  or  \vaggregates\v407..  Ambiguities may  also (but need not) arise when
several overloaded subprograms belonging to different \vpackages\v700. are visible.
These ambiguities can usually  be  resolved  in  several  ways:   \vqualified\v420.
\vexpressions\v420.  can  be  used  for  some or all actual parameters, and for the
result, if  any;   the  name  of  the  subprogram  can  be  expressed  more
explicitly as an expanded name;  finally, the subprogram can be renamed.
6.7  \uOverloading of Operators\n
The \vdeclaration\v301. of a function whose \vdesignator\v601. is  an  \voperator symbol\v601.  is
used  to  overload an \voperator\v411..  The sequence of \vcharacters\v201. of the operator
symbol must be either a \vlogical\v411., a \vrelational\v411., a  \vbinary  adding\v411.,  a  \vunary\v411.
\vadding\v411., a \vmultiplying\v411., or a \vhighest precedence operator\v411..  Neither
\vmembership  tests\v411.  nor  the  \vshort-circuit  control  forms\v411.  are  \vallowed\v108. as
function designators.
The subprogram specification  of  a  unary  operator  must  have  a  single
parameter.  The subprogram specification of a binary operator must have two
parameters;   for  each use of this operator, the first parameter takes the
left operand as \vactual parameter\v607., the  second  parameter  takes  the  right
operand.   Similarly,  a generic function instantiation whose designator is
an operator symbol is only allowed if  the  specification  of  the  generic
function  has  the corresponding number of parameters.  Default expressions
are not allowed for the parameters of an operator (whether the operator  is
declared  with  an  explicit  subprogram  specification  or  by  a  generic
instantiation).
For each of the operators "+" and "-", \voverloading\v610. is  allowed  both  as  a
unary and as a binary operator.
The explicit \vdeclaration of a function\v601. that overloads the \vequality operator\v411.
"=",  other  than  by  a  renaming  declaration,  is  only  allowed if both
parameters are of the same \vlimited type\v708..  An overloading of  equality  must
deliver  a  result  of  the  \vpredefined  type  BOOLEAN\v313.;  it also implicitly
overloads the \vinequality  operator\v413.  "/="  so  that  this  still  gives  the
\vcomplementary result\v413. to the equality operator.  Explicit overloading of the
inequality operator is not allowed.
A  renaming  declaration  whose designator is the equality operator is only
allowed to rename another equality operator.  (For example, such a renaming
declaration can be used when equality  is  \vvisible  by  selection\v803.  but  not
\vdirectly visible\v803..)
Note:
Overloading  of relational operators does not affect basic comparisons such
as testing for membership in a range or the choices in a case statement.
\uExamples:\n
    \ufunction\n "+" (LEFT, RIGHT : MATRIX) \ureturn\n MATRIX;
    \ufunction\n "+" (LEFT, RIGHT : VECTOR) \ureturn\n VECTOR;
    --  assuming that A, B, and C are of the type VECTOR
    --  the three following assignments are equivalent
    A := B + C;
    A := "+"(B, C);
    A := "+"(LEFT => B, RIGHT => C);
7. \uPackages\n
Packages  are  one of the four forms of \vprogram unit\v600., of which programs can
be composed.  The other forms are  \vsubprograms\v600.,  \vtask  units\v900.,  and  \vgeneric\v1200.
\vunits\v1200..
Packages  allow  the specification of groups of logically related entities.
In their simplest form packages specify pools of  common  object  and  \vtype\v306.
\vdeclarations\v306..   More  generally,  packages can be used to specify groups of
related entities including also subprograms that can be called from outside
the package, while their inner workings remain concealed and protected from
outside users.
More details:
 7.1    \vPackage Structure\v701.
 7.2    \vPackage Specifications and Declarations\v702.
 7.3    \vPackage Bodies\v703.
 7.4    \vPrivate Type and Deferred Constant Declarations\v704.
 7.5    \vExample of a Table Management Package\v709.
 7.6    \vExample of a Text Handling Package\v710.
7.1  \uPackage Structure\n
A  package is generally provided in two parts:  a package specification and
a \vpackage body\v703..  Every package has a package  specification,  but  not  all
packages have a package body.
    package_declaration ::= package_specification;
    package_specification ::=
        \upackage\n identifier \uis\n
          {\vbasic_declarative_item\v333.}
       [\uprivate\n
          {basic_declarative_item}]
        \uend\n [package_simple_name]
    package_body ::=
        \upackage body\n package_simple_name \uis\n
           [declarative_part]
       [\ubegin\n
            \vsequence_of_statements\v501.
       [\uexception\n
            exception_handler
           {\vexception_handler\v1102.}]]
        \uend\n [package_simple_name];
The  simple  name  at  the  start of a package body must repeat the package
\videntifier\v203..  Similarly if a \vsimple name\v401. appears at the end of  the  package
specification or body, it must repeat the package identifier.
If  a \vsubprogram declaration\v601., a package declaration, a \vtask declaration\v901., or
a  \vgeneric  declaration\v1201.  is  a  \vdeclarative  item\v333.  of   a   given   package
specification, then the body (if there is one) of the \vprogram unit\v600. declared
by  the  declarative  item  must  itself  be  a  declarative  item  of  the
\vdeclarative part\v333. of the body of the given package.
\uNotes:\n
A simple form of package, specifying a pool of \vobjects\v302. and \vtypes\v305., does  not
require  a  package  body.   One  of  the  possible uses of the sequence of
statements of a package body is  to  initialize  such  objects.   For  each
subprogram  declaration   there  must be a corresponding body (except for a
subprogram written in another language, as explained in section 13.9).   If
the  body  of  a  program  unit  is a \vbody stub\v1004., then a separately compiled
\vsubunit\v1004. containing the  corresponding  \vproper  body\v333.  is  required  for  the
program  unit  (see  10.2).   A body is not a basic declarative item and so
cannot appear in a package specification.
A package  declaration  is  either  a  library  package  (see  10.2)  or  a
declarative item declared within another program unit.
7.2  \uPackage Specifications and Declarations\n
The first list of \vdeclarative items\v333.  of  a \vpackage specification\v701. is  called
the  visible  part  of the \vpackage\v700..  The optional list of declarative items
after the reserved word private is called the private part of the  package.
An  entity declared in the private part of a package is not visible outside
the package itself  (a \vname\v401. denoting such an entity is only possible within
the package).  In contrast, \vexpanded names\v404. denoting  entities  declared  in
the visible part can be used even outside the package;  furthermore, \vdirect\v803.
\vvisibility\v803. of  such  entities can be achieved by means of \vuse clauses\v804. (see
4.1.3 and 8.4).
The \velaboration\v333. of a \vpackage declaration\v701. consists of the elaboration of its
\vbasic declarative items\v333. in the given order.
\uNotes:\n
The visible part of a package contains all  the  information  that  another
program  unit  is  able to know about the package.  A package consisting of
only a package specification (that is, without a package body) can be  used
to  represent a group of common \vconstants\v303. or \vvariables\v303., or a common pool of
objects and types, as in the examples below.
Example of a package describing a group of common variables:
    \upackage\n PLOTTING_DATA \uis\n
       PEN_UP : BOOLEAN;
       CONVERSION_FACTOR,
       X_OFFSET, Y_OFFSET,
       X_MIN,    Y_MIN,
       X_MAX,    Y_MAX:   REAL;     --  see 3.5.7
       X_VALUE : \uarray\n (1 .. 500) \uof\n REAL;
       Y_VALUE : \uarray\n (1 .. 500) \uof\n REAL;
    \uend\n PLOTTING_DATA;
Example of a package describing a common pool of objects and types:
    \upackage\n WORK_DATA \uis\n
       \utype\n DAY \uis\n (MON, TUE, WED, THU, FRI, SAT, SUN);
       \utype\n HOURS_SPENT \uis delta\n 0.25 \urange\n 0.0 .. 24.0;
       \utype\n TIME_TABLE  \uis array\n (DAY) \uof\n HOURS_SPENT;
       WORK_HOURS   : TIME_TABLE;
       NORMAL_HOURS : \uconstant\n TIME_TABLE :=
                         (MON .. THU => 8.25, FRI => 7.0, SAT | SUN => 0.0);
    \uend\n WORK_DATA;
7.3  \uPackage Bodies\n
In contrast to the entities declared in  the  \vvisible  part\v702.  of  a  \vpackage\v701.
\vspecification\v701.,  the  entities declared in the package body are only visible
within the package body itself.  As a consequence, a package with a package
body can be used for the construction of a group of related \vsubprograms\v600.  (a
package  in  the usual sense), in which the logical operations available to
the users are clearly isolated from the internal entities.
For the \velaboration\v301. of a  package  body,  its  \vdeclarative  part\v333.  is  first
elaborated,  and its \vsequence of statements\v501. (if any) is then executed.  The
optional  \vexception  handlers\v1102.  at  the  end  of  a  package  body   service
exceptions raised during the execution of the sequence of statements of the
package body.
\uNotes:\n
A  \vvariable\v303.  declared  in the body of a package is only visible within this
body and, consequently, its value can only be changed  within  the  package
body.   In the absence of local tasks, the value of such a variable remains
unchanged between calls issued from  outside  the  package  to  subprograms
declared  in  the  visible  part.   The  properties  of such a variable are
similar to those of an "own" variable of Algol 60.
The elaboration of the body of a subprogram declared in the visible part of
a package is caused by the elaboration of the body of the package.  Hence a
call of such a subprogram by an outside \vprogram unit\v600. raises  the  \vexception\v1100.
\vPROGRAM_ERROR\v1101. if the call takes place before the elaboration of the package
body (see 3.9).
Example of a package:
    \upackage\n RATIONAL_NUMBERS \uis\n
       \utype\n RATIONAL \uis\n
          \urecord\n
             NUMERATOR   : INTEGER;
             DENOMINATOR : POSITIVE;
          \uend record\n;
       \ufunction\n EQUAL(X,Y : RATIONAL) \ureturn\n BOOLEAN;
       \ufunction\n "/"  (X,Y : INTEGER)  \ureturn\n RATIONAL;  --  to construct a
                                                             rational number
       \ufunction\n "+"  (X,Y : RATIONAL) \ureturn\n RATIONAL;
       \ufunction\n "-"  (X,Y : RATIONAL) \ureturn\n RATIONAL;
       \ufunction\n "*"  (X,Y : RATIONAL) \ureturn\n RATIONAL;
       \ufunction\n "/"  (X,Y : RATIONAL) \ureturn\n RATIONAL;
    \uend\n;
    \upackage body\n RATIONAL_NUMBERS \uis\n
       \uprocedure\n SAME_DENOMINATOR (X,Y : \uin out\n RATIONAL) \uis\n
       \ubegin\n
          --  reduces X and Y to the same denominator:
          ...
       \uend\n;
       \ufunction\n EQUAL(X,Y : RATIONAL) \ureturn\n BOOLEAN \uis\n
          U,V : RATIONAL;
       \ubegin\n
          U := X;
          V := Y;
          SAME_DENOMINATOR (U,V);
          \ureturn\n U.NUMERATOR = V.NUMERATOR;
       \uend\n EQUAL;
       \ufunction\n "/" (X,Y : INTEGER) \ureturn\n RATIONAL \uis\n
       \ubegin\n
          \uif\n Y > 0 \uthen\n
             \ureturn\n (NUMERATOR => X,  DENOMINATOR => Y);
          \uelse\n
             \ureturn\n (NUMERATOR => -X, DENOMINATOR => -Y);
          \uend if\n;
       \uend\n "/";
       \ufunction\n "+" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ...  \uend\n "+";
       \ufunction\n "-" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ...  \uend\n "-";
       \ufunction\n "*" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ...  \uend\n "*";
       \ufunction\n "/" (X,Y : RATIONAL) \ureturn\n RATIONAL \uis\n ...  \uend\n "/";
    \uend\n RATIONAL_NUMBERS;
7.4  \uPrivate Type and Deferred Constant Declarations\n
The declaration of a \vtype\v305. as a \vprivate  type\v705.  in  the  visible  part  of  a
\vpackage\v700. serves to separate the characteristics that can be used directly by
outside  \vprogram  units\v600.  (that  is,  the  logical  properties)  from  other
characteristics whose direct use is confined to the package (the details of
the definition of the type itself).  \vDeferred constant\v707. \vdeclarations\v301. declare
\vconstants\v303. of private types.
    private_type_declaration ::=
       \utype\n identifier [\vdiscriminant_part\v326.] \uis\n [limited] \uprivate\n;
    deferred_constant_declaration ::=
       identifier_list : \uconstant\n \vtype_mark\v307.;
A private type declaration is only  allowed as a \vdeclarative  item\v333.  of  the
\vvisible  part\v702.  of  a package, or as the \vgeneric parameter declaration\v1201. for a
\vgeneric formal type\v1201. in a \vgeneric formal part\v1201.
The type mark of a deferred constant declaration must denote a private type
or a \vsubtype\v305. of a private type;  a deferred constant  declaration  and  the
declaration  of  the  corresponding  private  type must both be declarative
items of the visible  part  of  the  same  package.   A  deferred  constant
declaration  with several \videntifiers\v203. is equivalent to a sequence of single
deferred constant declarations as explained in section 3.2.
Examples of private type declarations:
    \utype\n KEY \uis private\n;
    \utype\n FILE_NAME \uis limited private\n;
Example of deferred constant declaration:
    NULL_KEY : \uconstant\n KEY;
More details:
 7.4.1  \vPrivate Types\v705.
 7.4.2  \vOperations of a Private Type\v706.
 7.4.3  \vDeferred Constants\v707.
 7.4.4  \vLimited Types\v708.
7.4.1  \uPrivate Types\n
If  a  private  \vtype declaration\v306. is given in the \vvisible part\v702. of a \vpackage\v700.,
then a corresponding declaration of a \vtype\v305. with the  same  \videntifier\v203.  must
appear  as  a  \vdeclarative  item\v333.  of  the \vprivate part\v702. of the package.  The
corresponding declaration must be either a full  type  declaration  or  the
declaration  of  a task type.  In the rest of this section explanations are
given in terms of \vfull type declarations\v306.;  the same  rules  apply  also  to
declarations of task types.
A  private  type  declaration  and  the corresponding full type declaration
define a single type.  The private  type  declaration,  together  with  the
visible  part,  define the \voperations\v305. that are available to outside program
units (see section 7.4.2 on the operations that are available  for  private
types).   On  the  other  hand,  the  full  type  declaration defines other
operations whose direct use is only possible within the package itself.
If the \vprivate type\v704. declaration includes  a  \vdiscriminant  part\v326.,  the  full
declaration  must  include a discriminant part that \vconforms\v604. (see 6.3.1 for
the conformance rules) and its  \vtype  definition\v306.  must  be  a  \vrecord  type\v325.
\vdefinition\325..  Conversely, if the \vprivate type declaration\v704. does not include a
discriminant part, the type declared by the full type declaration (the full
type)  must not be an unconstrained type with discriminants.  The full type
must not be an unconstrained \varray type\v321..  A \vlimited type\v708. (in  particular  a
task  type)  is allowed for the full type only if the \vreserved word\v211. limited
appears in the private type declaration (see 7.4.4).
Within the \vspecification of the package\v701. that declares a  private  type  and
before  the  end  of the corresponding full type declaration, a restriction
applies to the use of a \vname\v401. that denotes the private type or a \vsubtype\v305.  of
the  private type and, likewise, to the use of a name that denotes any type
or subtype that has a \vsubcomponent\v305. of the private type.  The  only  allowed
occurrences  of  such a name are in a \vdeferred constant declaration\v707., a type
or  \vsubtype  declaration\v307.,  a  \vsubprogram   specification\v601.,   or   an   \ventry\v905.
\vdeclaration\v905.;   moreover,  occurrences  within  \vderived  type definitions\v309. or
within simple \vexpressions\v410. are not allowed.
The \velaboration\v333. of a private type declaration creates a private  type.   If
the  private  type  declaration  has  a discriminant part, this elaboration
includes that of the discriminant part.  The elaboration of the  full  type
declaration  consists  of  the  elaboration  of  the  type definition;  the
discriminant  part,  if  any,  is  not  elaborated  (since  the  conforming
discriminant  part  of  the  private  type  declaration  has  already  been
elaborated).
\uNotes:\n
It follows from the given rules that neither the declaration of a  \vvariable\v303.
of  a  private  type,  nor the creation by an \vallocator\v421. of an object of the
private  type  are  allowed  before  the  full  declaration  of  the  type.
Similarly  before the full declaration, the name of the private type cannot
be used in a \vgeneric instantiation\v1206. or in a \vrepresentation clause\v1301..
7.4.2  \uOperations of a Private Type\n
The operations that are \vimplicitly declared\v301. by a private  type  \vdeclaration\v301.
include  basic operations.  These are the operations involved in \vassignment\v502.
(unless the reserved word limited appears in the  declaration),  \vmembership\v411.
\vtests\v411.,   selected   \vcomponents\v305.  for  the  selection  of  any  \vdiscriminant\v305.,
\vqualification\v420., and explicit \vconversions\v419..
For a \vprivate type\v704. T, the basic  \voperations\v305.  also  include  the  \vattributes\v405.
T'BASE  (see  3.3.3) and T'SIZE (see 13.7.2).  For an object A of a private
type, the \vbasic operations\v308.  include  the  attribute  A'CONSTRAINED  if  the
private type has discriminants (see 3.7.4), and in any case, the attributes
A'SIZE and A'ADDRESS (see 13.7.2).
Finally,  the  operations implicitly declared by a \vprivate type declaration\v704.
include the predefined comparison for \vequality\v413. and  inequality  unless  the
reserved word limited appears in the private type declaration.
The  above  operations,  together with \vsubprograms\v600. that have a parameter or
result of the private type and that are declared in the \vvisible\v702. part of the
\vpackage\v700., are the only  operations  from  the  package  that  are  available
outside the package for the private type.
Within   the  package  that  declares  the  private  type,  the  additional
operations implicitly declared  by  the  full  type  declaration  are  also
available.    However,   the  redefinition  of  these  implicitly  declared
operations is allowed within the same \vdeclarative region\v801., including between
the private type declaration and the corresponding  full  declaration.   An
explicitly  declared subprogram hides an implicitly declared operation that
has the same parameter and result type profile (this is  only  possible  if
the  implicitly  declared operation is a \vderived subprogram\v309. or a \vpredefined\v411.
\voperator\v411.).
If a composite type has subcomponents of a private  type  and  is  declared
outside  the  package  that  declares the private type, then the operations
that are implicitly declared by  the  declaration  of  the  composite  type
include  all operations that only depend on the characteristics that result
from the private type declaration alone.  (For example the  operator  <  is
not included for a one-dimensional array type.)
If  the  composite type is itself declared within the package that declares
the private type (including within an inner package  or  generic  package),
then  additional  operations that depend on the characteristics of the full
type are implicitly declared, as required by the rules  applicable  to  the
composite   type   (for   example   the   operator  <  is  declared  for  a
one-dimensional array type if the \vfull type\v705. is discrete).  These additional
operations are  implicitly  declared  at  the  earliest  place  within  the
\vimmediate  scope\v802. of the composite type and after the \vfull type declaration\v306..
The same rules apply to the operations that are implicitly declared for  an
access  type  whose designated type is a private type or a type declared by
an \vincomplete type declaration\v331..
For every private type or subtype T the following attribute is defined:
T'CONSTRAINED Yields  the  value  FALSE  if  T  denotes  an   unconstrained
              nonformal  private  type with discriminants;  also yields the
              value FALSE if T denotes a generic formal private  type,  and
              the associated actual subtype is either an unconstrained type
              with  discriminants  or  an unconstrained array type;  yields
              the value TRUE otherwise.  The value of this attribute is  of
              the predefined type BOOLEAN.
Note:
A  private  type  declaration  and  the corresponding full type declaration
define two different views of one  and  the  same  type.   Outside  of  the
defining  package  the characteristics of the type are those defined by the
visible part.  Within these outside  program  units  the  type  is  just  a
private  type  and  any language rule that applies only to another class of
types does not apply.  The fact that the full declaration  might  implement
the  private  type  with  a  type of a particular class (for example, as an
array type) is only relevant within the package itself.
The  consequences  of  this  actual  implementation  are,  however,   valid
everywhere.   For  example:  any default initialization of components takes
place;  the attribute SIZE provides  the  size  of  the  full  type;   \vtask\v904.
\vdependence\v904. rules still apply to components that are task objects.
Example:
    \upackage\n KEY_MANAGER \uis\n
       \utype\n KEY \uis private\n;
       NULL_KEY : constant KEY;
       \uprocedure\n GET_KEY(K : \uout\n KEY);
       \ufunction\n "<" (X, Y : KEY) \ureturn\n BOOLEAN;
    \uprivate\n
       \utype\n KEY \uis new\n NATURAL;
       NULL_KEY : \uconstant\n KEY := 0;
    \uend\n;
    \upackage body\n KEY_MANAGER \uis\n
       LAST_KEY : KEY := 0;
       \uprocedure\n GET_KEY(K : out KEY) \uis\n
       \ubegin\n
          LAST_KEY := LAST_KEY + 1;
          K := LAST_KEY;
       \uend\n GET_KEY;
       \ufunction\n "<" (X, Y : KEY) \ureturn\n BOOLEAN \uis\n
       \ubegin\n
          \ureturn\n INTEGER(X) < INTEGER(Y);
       \uend\n "<";
    \uend\n KEY_MANAGER;
Notes on the example:
Outside of the package KEY_MANAGER, the operations available for objects of
type KEY include assignment, the comparison for equality or inequality, the
procedure  GET_KEY  and  the  operator  "<";   they  do  not  include other
\vrelational operators\v411. such as ">=", or arithmetic operators.
The explicitly declared operator "<"  hides  the  predefined  operator  "<"
implicitly  declared  by the full type declaration.  Within the body of the
function, an explicit conversion  of  X  and  Y  to  the  type  INTEGER  is
necessary  to  invoke  the  "<"  operator of this type.  Alternatively, the
result of the function could be written as not (X >= Y), since the operator
">=" is not redefined.
The value of the variable LAST_KEY, declared in the package  body,  remains
unchanged  between  calls of the procedure GET_KEY.  (See also the Notes of
section 7.3.)
7.4.3  \uDeferred Constants\n
If  a  deferred  constant  declaration  is  given  in the \vvisible part\v702. of a
\vpackage\v700. then  a  constant  declaration  (that  is,  an  object  declaration
declaring a constant object, with an explicit initialization) with the same
\videntifier\v203.  must  appear  as  a \vdeclarative item\v333. of the \vprivate part\v702. of the
package.   This \vobject declaration\v303. is called the full  declaration  of  the
deferred  constant.   The  \vtype  mark\v307.  given  in  the full declaration must
\vconform\v604. to that given in the deferred  \vconstant  declaration\v604.  (see  6.3.1).
Multiple  or  single declarations are allowed for the deferred and the full
declarations, provided that the equivalent single declarations conform.
Within the \vspecification of the package\v701. that declares a  deferred  constant
and before the end of the corresponding full declaration, the use of a name
that  denotes  the  \vdeferred  constant\v704.  is  only  allowed  in  the  default
expression for a \vrecord component\v325. or for a  \vformal  parameter\v601.  (not  for  a
\vgeneric formal parameter\v1201.).
The \velaboration of a deferred constant declaration has no other effect\v301..
The  execution of a program is erroneous if it attempts to use the value of
a deferred constant  before  the  elaboration  of  the  corresponding  full
declaration.
Note:
The  full declaration for a deferred constant that has a given private type
must not appear before the corresponding full type declaration.  This is  a
consequence of the rules defining the allowed uses of a name that denotes a
private type (see 7.4.1).
7.4.4  \uLimited Types\n
A limited type is a type for which neither \vassignment\v502.  nor  the  predefined
comparison for \vequality\v413. and inequality is \vimplicitly declared\v301..
A \vprivate type declaration\704. that includes the reserved word limited declares
a  limited  type.   A  \vtask  type\v901. is a limited \vtype\v305..  A \vtype derived\v309. from a
limited type is itself a  limited  type.   Finally,  a  \vcomposite  type\v305.  is
limited if the type of any of its \vsubcomponents\v305. is limited.
The \voperations\v305. available for a private type that is limited are as given in
section 7.4.2 for private types except for the absence of assignment and of
a predefined comparison for equality and inequality.
For  a  \vformal parameter\v601. whose type is limited and whose declaration occurs
in an explicit \vsubprogram\v600. declaration, the \vmode\v1202. out is only allowed if this
type is private and the subprogram declaration occurs  within  the  visible
part  of  the  \vpackage\v700.  that declares the private type.  The same holds for
formal  parameters  of  entry  declarations  and   of   generic   procedure
declarations.   The corresponding \vfull type\v705. must not be limited if the mode
out is used for any such formal parameter.   Otherwise,  the  corresponding
full  type  is  allowed  (but  not  required)  to  be  a  limited  type (in
particular,  it  is  allowed  to  be  a  task  type).   If  the  full  type
corresponding  to  a  limited  private  type  is  not  itself limited, then
assignment for the type is available within the package, but  not  outside.
The following are consequences of the rules for limited types:
  -  An explicit initialization is not allowed in an \vobject declaration\v302.  if
     the type of the object is limited.
  -  A default expression is not allowed in a \vcomponent declaration\v325. if  the
     type of the \vrecord component\v325. is limited.
  -  An explicit \vinitial value\v303. is  not  allowed  in  an  \vallocator\v421.  if  the
     \vdesignated\v330. type is limited.
  -  A \vgeneric formal parameter\v1201. of mode in must not be of a  limited  type.
\uNotes:\n
The above rules do not exclude  a default expression for a formal parameter
of  a  limited  type;  they do not exclude a \vdeferred constant\v707. of a limited
type if the full type is  not  limited.   An  explicit  declaration  of  an
equality operator is allowed for a limited type (see 6.7).
\vAggregates\v407.  are  not  available for a limited composite type (see 3.6.2 and
3.7.4).  \vCatenation\v411. is not available for a limited array type (see  3.6.2).
Example:
    \upackage\n I_O_\UPACKAGE\N is
       \utype\n FILE_NAME \uis limited private\n;
       \uprocedure\n OPEN (F : \uin out\n FILE_NAME);
       \uprocedure\n CLOSE(F : \uin out\n FILE_NAME);
       \uprocedure\n READ (F : \uin\n FILE_NAME; ITEM : \uout\n INTEGER);
       \uprocedure\n WRITE(F : \uin\n FILE_NAME; ITEM : \uin\n  INTEGER);
    \uprivate\n
       \utype\n FILE_NAME \uis\n
          \urecord\n
             INTERNAL_NAME : INTEGER := 0;
          \uend record\n;
    \uend\n I_O_\UPACKAGE\N;
    \upackage body\n I_O_\UPACKAGE\N \uis\n
       LIMIT : \uconstant\n := 200;
       \utype\n FILE_DESCRIPTOR \uis record\n  ...  \uend record\n;
       DIRECTORY : \uarray\n (1 .. LIMIT) \uof\n FILE_DESCRIPTOR;
       ...
       \uprocedure\n OPEN (F : \uin out\n FILE_NAME) \uis\n  ...  \uend\n;
       \uprocedure\n CLOSE(F : \uin out\n FILE_NAME) \uis\n  ...  \uend\n;
       \uprocedure\n READ (F : \uin\n FILE_NAME; ITEM : \uout\n INTEGER) \uis\n ... \uend\n;
       \uprocedure\n WRITE(F : \uin\n FILE_NAME; ITEM : \uin\n  INTEGER) \uis\n ... \uend\n;
    \ubegin\n
       ...
    \uend\n I_O_PACKAGE;
Notes on the example:
In  the  example above, an outside subprogram making use of I_O_PACKAGE may
obtain a file name by calling OPEN and later use it in calls  to  READ  and
WRITE.  Thus, outside the package, a file name obtained from OPEN acts as a
kind  of  password;   its internal properties (such as containing a numeric
value) are  not  known  and  no  other  operations  (such  as  addition  or
comparison of internal names) can be performed on a file name.
This  example is characteristic of any case where complete control over the
operations of a type is desired.  Such packages serve a dual purpose.  They
prevent a user from making use of the internal structure of the type.  They
also implement the notion of an  encapsulated  data  type  where  the  only
operations on the type are those given in the package specification.
7.5  \uExample of a Table Management Package\n
The  following  example  illustrates  the use of packages in providing high
level procedures with a simple interface to the user.
The problem is to define a  table  management  package  for  inserting  and
retrieving  items.   The  items  are  inserted  into  the table as they are
supplied.  Each inserted item has an order number.  The items are retrieved
according to their order number, where  the  item  with  the  lowest  order
number is retrieved first.
From  the  user's  point  of view, the package is quite simple.  There is a
type called ITEM designating table items, a procedure INSERT for  inserting
items,  and  a  procedure  RETRIEVE  for obtaining the item with the lowest
order number.  There is a special item NULL_ITEM that is returned when  the
table  is  empty,  and an exception TABLE_FULL which is raised by INSERT if
the table is already full.
A sketch of such a package is given below.  Only the specification  of  the
package is exposed to the user.
    \upackage\n TABLE_MANAGER \uis\n
       \utype\n ITEM \uis\n
          \urecord\n
             ORDER_NUM : INTEGER;
             ITEM_CODE : INTEGER;
             QUANTITY  : INTEGER;
             ITEM_TYPE : CHARACTER;
          \uend record\n;
       NULL_ITEM : \uconstant\n ITEM :=
          (ORDER_NUM | ITEM_CODE | QUANTITY => 0, ITEM_TYPE => ' ');
       \uprocedure\n INSERT  (NEW_ITEM   : \uin\n  ITEM);
       \uprocedure\n RETRIEVE(FIRST_ITEM : \uout\n ITEM);
       TABLE_FULL : \uexception\n;  --  raised by INSERT when table full
    \uend\n;
The  details  of  implementing such packages can be quite complex;  in this
case they involve a two-way  linked  table  of  internal  items.   A  local
housekeeping  procedure  EXCHANGE  is used to move an internal item between
the busy and the free lists.  The initial table linkages are established by
the initialization part.  The package body need not be shown to  the  users
of the package.
    \upackage body\n TABLE_MANAGER \uis\n
       SIZE : \uconstant\n := 2000;
       \usubtype\n INDEX \uis\n INTEGER \urange\n 0 .. SIZE;
       \utype\n INTERNAL_ITEM \uis\n
          \urecord\n
             CONTENT : ITEM;
             SUCC    : INDEX;
             PRED    : INDEX;
          \uend record\n;
       TABLE : \uarray\n (INDEX) \uof\n INTERNAL_ITEM;
       FIRST_BUSY_ITEM : INDEX := 0;
       FIRST_FREE_ITEM : INDEX := 1;
       \ufunction\n FREE_LIST_EMPTY \ureturn\n BOOLEAN \uis\n ... \uend\n;
       \ufunction\n BUSY_LIST_EMPTY \ureturn\n BOOLEAN \uis\n ... \uend\n;
       \uprocedure\n EXCHANGE (FROM : \uin\n INDEX; TO : \uin\n INDEX) \uis\n ... \uend\n;
       \uprocedure\n INSERT (NEW_ITEM : \uin\n ITEM) \uis\n
       \ubegin\n
          \uif\n FREE_LIST_EMPTY \uthen\n
             \uraise\n TABLE_FULL;
          \uend if\n;
          --  remaining code for INSERT
       \uend\n INSERT;
       \uprocedure\n RETRIEVE (FIRST_ITEM : \uout\n ITEM) \uis\n ... \uend\n;
    \ubegin\n
       --  initialization of the table linkages
    \uend\n TABLE_MANAGER;
7.6  \uExample of a Text Handling Package\n
This  example  illustrates  a simple text handling package.  The users only
have access to the visible part;  the implementation is hidden from them in
the private part and the package body (not shown).
From a user's point of view, a TEXT is a variable-length string.  Each text
object has a maximum length,  which  must  be  given  when  the  object  is
declared,  and  a  current  value, which is a string of some length between
zero and the maximum.  The maximum possible length of a text object  is  an
implementation-defined constant.
The  package  defines first the necessary types, then functions that return
some characteristics of objects of the type, then the conversion  functions
between  texts  and  the predefined CHARACTER and STRING types, and finally
some of the standard operations on varying strings.   Most  operations  are
overloaded  on strings and characters as well as on the type TEXT, in order
to minimize the number of explicit conversions the user has to write.
    \upackage\n TEXT_HANDLER \uis\n
       MAXIMUM : \uconstant\n := SOME_VALUE;  --  implementation-defined
       \usubtype\n INDEX \uis\n INTEGER \urange\n 0 .. MAXIMUM;
       \utype\n TEXT(MAXIMUM_LENGTH : INDEX) \uis limited private\n;
       \ufunction\n LENGTH (T : TEXT) \ureturn\n INDEX;
       \ufunction\n VALUE  (T : TEXT) \ureturn\n STRING;
       \ufunction\n EMPTY  (T : TEXT) \ureturn\n BOOLEAN;
       \ufunction\n TO_TEXT (S : STRING;    MAX : INDEX) \ureturn\n TEXT;
                                                     --  maximum length MAX
       \ufunction\n TO_TEXT (C : CHARACTER; MAX : INDEX) \ureturn\n TEXT;
       \ufunction\n TO_TEXT (S : STRING)    \ureturn\n TEXT;
                                                --  maximum length S'LENGTH
       \ufunction\n TO_TEXT (C : CHARACTER) \ureturn\n TEXT;
       \ufunction\n "&" (LEFT : TEXT;      RIGHT : TEXT)      \ureturn\n TEXT;
       \ufunction\n "&" (LEFT : TEXT;      RIGHT : STRING)    \ureturn\n TEXT;
       \ufunction\n "&" (LEFT : STRING;    RIGHT : TEXT)      \ureturn\n TEXT;
       \ufunction\n "&" (LEFT : TEXT;      RIGHT : CHARACTER) \ureturn\n TEXT;
       \ufunction\n "&" (LEFT : CHARACTER; RIGHT : TEXT)      \ureturn\n TEXT;
       \ufunction\n "="  (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN;
       \ufunction\n "<"  (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN;
       \ufunction\n "<=" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN;
       \ufunction\n ">"  (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN;
       \ufunction\n ">=" (LEFT : TEXT; RIGHT : TEXT) \ureturn\n BOOLEAN;
       \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n TEXT);
       \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n STRING);
       \uprocedure\n SET (OBJECT : \uin out\n TEXT; VALUE : \uin\n CHARACTER);
       \uprocedure\n APPEND (TAIL : \uin\n TEXT;      TO : \uin out\n TEXT);
       \uprocedure\n APPEND (TAIL : \uin\n STRING;    TO : \uin out\n TEXT);
       \uprocedure\n APPEND (TAIL : \uin\n CHARACTER; TO : \uin out\n TEXT);
  \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n TEXT; POSITION :
                                                                 \uin\n INDEX);
  \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n STRING; POSITION :
                                                                 \uin\n INDEX);
  \uprocedure\n AMEND (OBJECT : \uin out\n TEXT; BY : \uin\n CHARACTER; POSITION :
                                                                 \uin\n INDEX);
- amend replaces part of the object by the given text, string, or character
- starting at the given position in the object
       \ufunction\n LOCATE (FRAGMENT : TEXT;      WITHIN : TEXT) \ureturn\n INDEX;
       \ufunction\n LOCATE (FRAGMENT : STRING;    WITHIN : TEXT) \ureturn\n INDEX;
       \ufunction\n LOCATE (FRAGMENT : CHARACTER; WITHIN : TEXT) \ureturn\n INDEX;
       --  all \ureturn\n 0 if the fragment is not located
    \uprivate\n
       \utype\n TEXT(MAXIMUM_LENGTH : INDEX) \uis\n
          \urecord\n
             POS   : INDEX := 0;
             VALUE : STRING(1 .. MAXIMUM_LENGTH);
          \uend record\n;
    \uend\n TEXT_HANDLER;
Example of use of the text handling package:
A program opens an output file, whose name is supplied by the string  NAME.
This string has the form
    [DEVICE :] [FILENAME [.EXTENSION]]
There  are  standard  defaults  for  device,  filename, and extension.  The
user-supplied name is passed to EXPAND_FILE_NAME as a  parameter,  and  the
result is the expanded version, with any necessary defaults added.
    \ufunction\n EXPAND_FILE_NAME (NAME : STRING) \ureturn\n STRING is
       \uuse\n TEXT_HANDLER;
       DEFAULT_DEVICE    : \uconstant\n STRING := "SY:";
       DEFAULT_FILE_NAME : \uconstant\n STRING := "RESULTS";
       DEFAULT_EXTENSION : \uconstant\n STRING := ".DAT";
       MAXIMUM_FILE_NAME_LENGTH : \uconstant\n INDEX := SOME_APPROPRIATE_VALUE;
       FILE_NAME : TEXT(MAXIMUM_FILE_NAME_LENGTH);
    \ubegin\n
       SET(FILE_NAME, NAME);
       \uif\n EMPTY(FILE_NAME) \uthen\n
          SET(FILE_NAME, DEFAULT_FILE_NAME);
       \uend if\n;
       \uif\n LOCATE(':', FILE_NAME) = 0 \uthen\n
          SET(FILE_NAME, DEFAULT_DEVICE & FILE_NAME);
       \uend if\n;
       \uif\n LOCATE('.', FILE_NAME) = 0 \uthen\n
          APPEND(DEFAULT_EXTENSION, TO => FILE_NAME);
       \uend if\n;
       \ureturn\n VALUE(FILE_NAME);
    \uend\n EXPAND_FILE_NAME;
8. \uVisibility Rules\n
The  rules  defining the \vscope\v802. of \vdeclarations\v301. and the rules defining which
\videntifiers\v203. are visible at various points in the text of  the  program  are
described  in this chapter.  The formulation of these rules uses the notion
of a \vdeclarative region\v801..
More details:
8.1    \vDeclarative Region\v801.
8.2    \vScope of Declarations\v802.
8.3    \vVisibility\v803.
8.4    \vUse Clauses\v804.
8.5    \vRenaming Declarations\v805.
8.6    \vThe Package Standard\v806.
8.7    \vThe Context of Overload Resolution\v807.
8.1  Declarative Region
A  declarative  region  is  a  portion  of  the  program  text. A  single
declarative region is formed by the text of each of the following:
-  A subprogram \vdeclaration\v301., a \vpackage declaration\v701., a  task  declaration,
or  a  \vgeneric  declaration\v1201.,  together with the corresponding body, if
any.  If the body is a \vbody stub\v1004., the declarative region also includes
the corresponding \vsubunit\v1004..  If the program unit has subunits, they are
also included.
-  An  \ventry  declaration\v905.  together   with   the   corresponding accept
statements.
-  A \vrecord type\v325. declaration, together with a  corresponding private  or
\vincomplete  type declaration\v331. if any, and together with a corresponding
\vrecord representation clause\v1304. if any.
-  A \vrenaming declaration\v805. that includes  a  \vformal  part\v601.,  or  a \vgeneric\v1201.
\vparameter  declaration\v1201.  that  includes  either  a  formal  part or  a
\vdiscriminant part\v326..
-  A \vblock statement\v507. or a \vloop statement\v506..
In each of the above cases, the declarative region is said to be associated
with the corresponding declaration or statement.  A declaration is said  to
occur  immediately  within  a  declarative  region  if  this  region is the
innermost  region  that  encloses  the  declaration,   not counting   the
declarative region (if any) associated with the declaration itself.
A  declaration  that occurs immediately within a declarative region is said
to be local to the region.  Declarations in outer (enclosing) regions  are
said  to  be  global  to  an  inner (enclosed) declarative region.  A local
entity is one declared by a local declaration;   a  global  entity  is  one
declared by a global declaration.
Some  of  the  above  forms  of declarative region include several disjoint
parts (for example, other declarative items can be between the declaration
of  a  \vpackage\v700.  and  its  body).   Each  declarative region is nevertheless
considered as a (logically) continuous portion of the program text.   Hence
if  any  rule defines  a portion of text as the text that extends from some
specific point of a declarative region to the end of this region, then this
portion is the corresponding subset of the declarative region (for  example
it does not include intermediate declarative items between the two parts of
a package).
\uNotes:\n
As   defined   in   section   3.1,  the  term  declaration  includes  basic
declarations, \vimplicit declarations\v301., and those declarations that are  part
of   \vbasic   declarations\v301.,   for   example,   discriminant   and \vparameter\v601.
\vspecifications\v601..  It follows from the definition  of  a  declarative  region
that  a  \vdiscriminant  specification\v326.  occurs  immediately within the region
associated with  the  enclosing  record  type  declaration.   Similarly,  a
parameter  specification  occurs  immediately  within the region associated
with the enclosing \vsubprogram body\v603. or \vaccept statement\v905..
The \vpackage STANDARD\v806. forms a declarative region which encloses all  \vlibrary\v701.
\vunits\v701.:   the  implicit declaration of each library unit is assumed to occur
immediately within this package (see sections 8.6 and 10.1.1).
Declarative regions can be nested within other  declarative  regions.   For
example,  subprograms,  packages,  \vtask  units\v900.,  generic  units, and block
statements can be nested within each other, and  can  contain record  type
declarations, loop statements, and accept statements.
8.2  \uScope of Declarations\n
For  each  form of \vdeclaration\v301., the language rules define a certain portion
of the program text called the scope of the declaration.  The  scope  of  a
declaration  is  also  called  the  scope  of  any  entity  declared by the
declaration.  Furthermore, if the declaration associates some notation with
a declared entity, this portion of the text is also  called  the  scope  of
this  notation  (either  an  \videntifier\v203.,  a  \vcharacter literal\v207., an \voperator\v601.
\vsymbol\v601., or the notation for a \vbasic operation\v308.).  Within  the  scope  of  an
entity,  and  only  there,  there  are  places where it is legal to use the
associated notation in order to refer to the declared entity.  These places
are defined by the rules of \vvisibility\v803. and \voverloading\v610..
The scope of a declaration that \voccurs  immediately  within\v801.  a  \vdeclarative\v801.
\vregion\v801.  \vextends\v801.  from  the  beginning  of the declaration to the end of the
declarative region;  this part of the scope of a declaration is called  the
immediate  scope.   Furthermore,  for any of the declarations listed below,
the scope of the declaration extends beyond the immediate scope:
(a)  A declaration that occurs immediately within the  visible  part  of  a
\vpackage declaration\v701..
(b)  An \ventry declaration\v905..
(c)  A \vcomponent declaration\v325..
(d)  A \vdiscriminant specification\v326..
(e)  A \vparameter specification\v601..
(f)  A \vgeneric parameter declaration\v1201..
In  each  of  these  cases, the given declaration occurs immediately within
some enclosing declaration, and the scope of the given declaration  extends
to the end of the scope of the enclosing declaration.
In  the  absence  of a \vsubprogram declaration\v601., the subprogram specification
given in the \vsubprogram body\v603. or in the \vbody stub\v1004. acts  as  the  declaration
and rule (e) applies also in such a case.
Note:
The  above scope rules apply to all forms of declaration defined by section
3.1;  in particular, they apply also to \vimplicit  declarations\v301..   Rule  (a)
applies  to a package declaration and thus not to the \vpackage specification\v701.
of a \vgeneric declaration\v1201..  For nested declarations, the rules  (a)  through
(f)  apply  at  each level.  For example, if a task unit is declared in the
\vvisible part\v702. of a package, the scope of an entry of the \vtask  unit\v900.  extends
to  the end of the scope of the task unit, that is, to the end of the scope
of the enclosing package.  The scope of a \vuse clause\v804. is defined in  section
8.3  \uVisibility\n
The meaning of the occurrence of an \videntifier\v203. at a given place in the text
is defined by the visibility rules and also,  in  the  case  of  \voverloaded\v610.
\vdeclarations\v301., by the overloading rules.  The identifiers considered in this
chapter  include  any  identifier  other than a \vreserved word\v211., an attribute
designator, a \vpragma identifier\v210., the identifier of a pragma \vargument\v210., or an
identifier given as a pragma  argument.   The  places  considered  in  this
chapter  are  those where a \vlexical element\v202. (such as an identifier) occurs.
The overloaded declarations  considered  in  this  chapter  are  those  for
\vsubprograms\v600., enumeration literals, and single entries.
For  each  identifier  and  at each place in the text, the visibility rules
determine a set of declarations (with this identifier) that define possible
meanings of an occurrence of the identifier.  A declaration is said  to  be
\vvisible\v702.  at  a  given  place  in the text when, according to the visibility
rules, the declaration defines a possible meaning of this occurrence.   Two
cases arise.
-  The visibility rules determine at most one possible meaning.  In  such
a   case   the  visibility  rules  are  sufficient  to  determine  the
declaration defining the meaning of the occurrence of the  identifier,
or  in  the  absence  of  such  a  declaration,  to determine that the
occurrence is not legal at the given point.
-  The visibility rules determine more than  one  possible  meaning.   In
such a case the occurrence of the identifier is legal at this point if
and  only  if  exactly  one  visible declaration is acceptable for the
overloading rules in the given context (see section 6.6 for the  rules
of  overloading  and  section  8.7  for  the context used for overload
resolution).
A declaration is only visible within a certain part  of  its  \vscope\v802.;   this
part   starts   at   the  end  of  the  declaration  except  in  a  \vpackage\v700.
specification, in which case it starts at the reserved word is given  after
the  identifier  of  the  package  specification.   (This  rule applies, in
particular, for \vimplicit declarations\v301..)
Visibility is either by selection or direct.  A declaration is  visible  by
selection at places that are defined as follows.
(a)  For a declaration given in the visible part of a package  declaration:
at  the  place of the \vselector\v404. after the dot of an \vexpanded name\v404. whose
prefix denotes the package.
(b)  For an \ventry declaration\v905. of a given \vtask type\v901.:  at the  place  of  the
selector  after  the  dot  of  a  \vselected  component\v404.  whose prefix is
appropriate for the task type.
(c)  For a \vcomponent declaration\v325. of a given record  \vtype  declaration\v305.:   at
the  place of the selector after the dot of a \vselected component\v404. whose
prefix is \vappropriate for the type\v401.;  also at the place of a  component
simple  name  (before  the \vcompound delimiter\v202. =>) in a named component
association of an \vaggregate\v407. of the type.
(d)  For a \vdiscriminant specification\v326. of a given \vtype declaration\v306.:  at  the
same  places  as  for a component declaration;  also at the place of a
discriminant \vsimple name\v401. (before the compound delimiter =>) in a named
discriminant association of a \vdiscriminant constraint\v327. for the type.
(e)  For a \vparameter specification\v601. of a given subprogram  specification  or
entry  declaration:   at the place of the \vformal parameter\v601. (before the
compound  delimiter  =>)  in  a  named  \vparameter  association\v606.  of   a
corresponding subprogram or \ventry call\v905..
(f)  For a \vgeneric parameter declaration\v1201. of a given \vgeneric unit\v1200.:   at  the
place  of  the \vgeneric formal parameter\v1201. (before the compound delimiter
=>)  in  a  named  \vgeneric  association\v1206.  of  a  corresponding  generic
instantiation.
Finally,  within  the  \vdeclarative region\v801. associated with a construct other
than a \vrecord type\v325. declaration, any  declaration  that  \voccurs  immediately\v801.
\vwithin\v801.  the  region  is  visible  by selection at the place of the selector
after the dot of an expanded name whose prefix denotes the construct.
Where it is not visible by selection, a visible declaration is said  to  be
directly  visible.  A declaration is directly visible within a certain part
of its \vimmediate scope\v802.;  this part extends to  the  end  of  the  immediate
scope  of  the  declaration,  but  excludes places where the declaration is
hidden  as  explained  below.   In  addition,   a   declaration   occurring
immediately  within  the  visible  part  of  a package can be made directly
visible by means of a \vuse  clause\v804.  according  to  the  rules  described  in
section  8.4.   (See also section 8.6 for the visibility of \vlibrary units\v1001..)
A declaration is said to be hidden within (part of)  an  inner  declarative
region  if  the inner region contains a homograph of this declaration;  the
outer declaration is then hidden within the immediate scope  of  the  inner
homograph.  Each of two declarations is said to be a homograph of the other
if  both  declarations  have the same identifier and overloading is allowed
for  at  most  one  of  the  two.   If  overloading  is  allowed  for  both
declarations, then each of the two is a homograph of the other if they have
the  same identifier, \voperator symbol\v601., or \vcharacter literal\v207., as well as the
same \vparameter\v602. and \vresult type profile\v805.
Within the specification of a subprogram, every declaration with  the  same
designator  as  the  subprogram is hidden;  the same holds within a \vgeneric\v1206.
\vinstantiation\v1206. that declares a subprogram, and within an  entry  declaration
or  the formal part of an \vaccept statement\v905.;  where hidden in this manner, a
declaration is visible neither by selection  nor directly.
Two declarations that occur immediately within the same declarative  region
must not be homographs, unless either or both of the following requirements
are  met:   (a)  exactly  one  of  them  is  the  implicit declaration of a
predefined operation;  (b) exactly one of them is the implicit  declaration
of  a  derived subprogram.  In such cases, a predefined operation is always
hidden by the other homograph;  a derived  subprogram  hides  a  predefined
operation,  but  is  hidden  by  any other homograph.  Where hidden in this
manner, an implicit declaration is hidden within the entire  scope  of  the
other  declaration  (regardless  of  which  declaration occurs first);  the
implicit declaration is visible neither by selection nor directly.
Whenever a declaration with a certain identifier is visible  from  a  given
point,  the identifier and the declared entity (if any) are also said to be
visible from that point.  Direct visibility and visibility by selection are
likewise defined for character literals and operator symbols.  An  \voperator\v411.
is  directly  visible if and only if the corresponding operator declaration
is directly  visible.   Finally,  the  notation  associated  with  a  \vbasic\v308.
\voperation\v308. is directly visible within the entire scope of this operation.
Example:
procedure P is
A, B : BOOLEAN;
procedure Q is
C : BOOLEAN;
B : BOOLEAN;  --  an inner homograph of B
begin
B := A;    --  means Q.B := P.A;
C := P.B;  --  means Q.C := P.B;
begin
A := B;  --  means P.A := P.B;
Note on the visibility of library units:
The  visibility of library units is determined by with clauses (see 10.1.1)
and by the fact that library units are implicitly declared in  the  package
STANDARD (see 8.6).
Note on homographs:
The  same  identifier  may  occur in different declarations and may thus be
associated  with  different  entities,  even  if  the   scopes   of   these
declarations  overlap.  Overlap of the scopes of declarations with the same
identifier can result from overloading of subprograms  and  of  enumeration
literals.   Such  overlaps  can also occur for entities declared in package
visible parts and for entries, record  components,  and  parameters,  where
there  is overlap of the scopes of the enclosing package declarations, task
declarations, record type declarations, subprogram  declarations,  renaming
declarations,  or  generic  declarations.   Finally  overlapping scopes can
result from nesting.
Note on immediate scope, hiding, and visibility:
The rules defining immediate scope, hiding, and  visibility  imply  that  a
reference  to  an  identifier within its own declaration is illegal (except
for packages and \vgeneric packages\v1201. ).  The identifier hides outer  homographs
within  its  immediate  scope, that is,  from the start of the declaration;
on the other hand, the identifier is visible only  after  the  end  of  the
declaration.    For  this  reason,  all  but  the  last  of  the  following
declarations are illegal:
K : INTEGER := K * K;              --  illegal
T : T;                             --  illegal
procedure P(X : P);                --  illegal
procedure Q(X : REAL := Q);        --  illegal, even if there is a
--  function named Q
procedure R(R : REAL);   --  an inner declaration is legal (although
--  confusing)
8.4  \uUse Clauses\n
A  use clause achieves direct visibility of \vdeclarations\v301. that appear in the
\vvisible parts\v702. of named \vpackages\v700..
use_clause ::= use package_name {, package_name};
For each use clause, there is a certain region of text called the \vscope\v802.  of
the use clause.  This region starts immediately after the use clause.  If a
use  clause  is a \vdeclarative item\v333. of some \vdeclarative region\v801., the scope of
the clause \vextends\v801. to the end of the declarative region.  If a  use  clause
occurs  within a \vcontext clause\v1001. of a \vcompilation unit\v1001., the scope of the use
clause extends to the end of the declarative  region  associated  with  the
compilation unit.
In  order to define which declarations are made \vdirectly visible\v803. at a given
place by use clauses, consider the set of packages named by all use clauses
whose scopes enclose this place, omitting from this set any  packages  that
enclose  this  place.  A declaration that can be made directly visible by a
use clause (a potentially visible  declaration)  is  any  declaration  that
\voccurs  immediately  within\v801.  the  visible  part of a package of the set.  A
potentially visible declaration is actually made directly visible except in
the following two cases:
-  A potentially visible declaration is not made directly visible if  the
place  considered  is within the \vimmediate scope\v802. of a \vhomograph\v803. of the
declaration.
-  Potentially visible declarations that have the same \videntifier\v203. are not
made directly visible unless each of them  is  either  an  \venumeration\v311.
\vliteral  specification\v311.  or  the  declaration  of  a  subprogram  (by a
\vsubprogram   declaration\v601.,   a   renaming   declaration,   a    generic
instantiation, or an implicit declaration).
The \velaboration\v301. of a use clause has no other effect.
Note:
The  above rules guarantee that a declaration that is made directly visible
by a use clause cannot hide an otherwise directly visible declaration.  The
above rules are formulated in terms of the set of packages  named  by  use
clauses.
Consequently,  the  following  lines  of  text  all  have  the  same effect
(assuming only one package P).
use P;
use P; use P, P;
Example of conflicting names in two packages:
procedure R is
package TRAFFIC is
type COLOR is (RED, AMBER, GREEN);
end TRAFFIC;
package WATER_COLORS is
type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
end WATER_COLORS;
use TRAFFIC;      -- COLOR, RED, AMBER, and GREEN are directly visible
use WATER_COLORS; --  two homographs of GREEN are directly visible
--  but COLOR is no longer directly visible
subtype LIGHT is TRAFFIC.COLOR;      --Subtypes are used to resolve
subtype SHADE is WATER_COLORS.COLOR; --the conflicting type name COLOR
SIGNAL : LIGHT;
PAINT  : SHADE;
begin
SIGNAL := GREEN;  --  that of TRAFFIC
PAINT  := GREEN;  --  that of WATER_COLORS
end R;
Example of \vname\v401. identification with a use clause:
package D is
T, U, V : BOOLEAN;
end D;
procedure P is
package E is
B, W, V : INTEGER;
end E;
procedure Q is
T, X : REAL;
use D, E;
begin
--  the name T means Q.T, not D.T
--  the name U means D.U
--  the name B means E.B
--  the name W means E.W
--  the name X means Q.X
--  the name V is illegal : either D.V or E.V must be used
end Q;
begin
end P;
8.5  \uRenaming Declarations\n
A renaming \vdeclaration\v301. declares another \vname\v401. for an entity.
renaming_declaration ::=
identifier : type_mark   renames object_name;
| identifier : exception   renames exception_name;
| \vpackage\v700. identifier       renames package_name;
| subprogram_specification renames subprogram_or_entry_name;
The  \velaboration\v301.  of a renaming declaration evaluates the name that follows
the \vreserved word\v211. renames and thereby determines the entity denoted by this
name (the renamed entity).  At any point where a  renaming  declaration  is
visible, the identifier, or \voperator symbol\v601. of this declaration denotes the
renamed entity.
The first form of renaming declaration is used for the renaming of \vobjects\v302..
The  renamed  entity  must  be an object of the \vbase type\v305. of the \vtype mark\v305..
The properties of the renamed object  are  not  affected  by  the  renaming
declaration.   In particular, its value and whether or not it is a \vconstant\v303.
are unaffected;  similarly, the \vconstraints\v305. that apply to an object are not
affected by renaming (any constraint  implied  by  the  type  mark  of  the
renaming  declaration  is ignored).  The renaming declaration is \vlegal\v108. only
if exactly one object has this type and can be denoted by the object  name.
The  following  restrictions  apply  to the renaming of a \vsubcomponent\v305. that
\vdepends on discriminants\v326. of a \vvariable\v303..  The renaming is not allowed if the
\vsubtype\v307. of the variable, as defined in a corresponding \vobject  declaration\v302.,
component declaration, or component subtype indication, is an unconstrained
type;   or  if  the  variable  is a generic formal object (of \vmode\v601. in out).
Similarly if the variable is  a  \vformal  parameter\v601.,  the  renaming  is  not
allowed  if  the  type mark given in the \vparameter specification\v601. denotes an
nconstrained type whose \vdiscriminants\v326. have \vdefault expressions\v601..
The second form of  renaming  declaration  is  used  for  the  renaming  of
exceptions;  the third form, for the renaming of packages.
The  last  form  of  renaming  declaration  is  used  for  the  renaming of
\vsubprograms\v600.  and  entries.   The  renamed  subprogram  or  \ventry\v905.  and   the
subprogram  specification  given  in the renaming declaration must have the
same \vparameter\v602. and result type profile (see 6.6).  The renaming declaration
is legal only if exactly one visible  subprogram  or  entry  satisfies  the
above  requirements  and  can  be  denoted by the given subprogram or entry
name.  In addition, parameter modes must be identical for formal parameters
that are at the same parameter position.
The subtypes of the parameters and result (if any) of a renamed  subprogram
or  entry  are not affected by renaming.  These subtypes are those given in
the  original  \vsubprogram  declaration\v601.,  generic  instantiation,  or  entry
declaration  (not  those of the renaming declaration);  even for calls that
use the new name.  On the other hand, a renaming declaration can  introduce
parameter  names  and  default  expressions  that  differ from those of the
renamed subprogram;  named associations of calls with  the  new  subprogram
name  must  use the new parameter name;  calls with the old subprogram name
must use the old parameter names.
A \vprocedure\v601. can only be renamed as a procedure.  Either of  a  \vfunction\v609.  or
\voperator\v611.  can be renamed as either of a function or operator;  for renaming
as  an  operator,  the  \vsubprogram  specification\v601.  given  in  the  renaming
declaration  is  subject  to  the  rules  given in section 6.7 for \voperator\v611.
\vdeclarations\v611..   \vEnumeration  literals\v311.  can   be   renamed   as   functions;
similarly,  attributes  defined as functions (such as SUCC and PRED) can be
renamed as functions.  An entry can only be renamed as  a  procedure;   the
new name is only allowed to appear in contexts that \vallow\v108. a procedure name.
An \ventry of a family\v905. can be renamed, but an entry family cannot be renamed
as a whole.
\uExamples:\n
declare
L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1
begin
L.AGE := L.AGE + 1;
FULL : \vexception\v1100. renames TABLE_MANAGER.TABLE_FULL; -- see 7.5
package TM renames TABLE_MANAGER;
function REAL_PLUS(LEFT, RIGHT : REAL   ) return REAL    renames "+";
function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+";
function ROUGE return COLOR renames RED;  --  see 3.5.1
function ROT   return COLOR renames RED;
function ROSSO return COLOR renames ROUGE;
function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5
Example of a renaming declaration with new parameter names:
function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1
Example of a renaming declaration with a new default expression:
function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL;
-- see 6.1
\uNotes:\n
Renaming may be used to resolve name conflicts and to act as  a  shorthand.
Renaming  with  a different \videntifier\v203. or operator symbol does not hide the
old name;  the new name and the old name need not be \vvisible\v803.  at  the  same
points.    The   attributes  POS  and  VAL  cannot  be  renamed  since  the
corresponding specifications cannot be written;  the  same  holds  for  the
predefined multiplying operators with a universal_fixed result.
Calls  with  the  new name of a renamed entry are \vprocedure call statements\v606.
and are not allowed at places where  the  syntax  requires  an  \ventry  call\v905.
\vstatement\v905.  in  \vconditional  and  timed  entry  calls\v909.;  similarly, the COUNT
\vattribute\v405. is not available for the new name.
A \vtask object\v902. that is declared by an object declaration can be  renamed  as
an   object.    However,   a  single  task  cannot  be  renamed  since  the
corresponding task type is anonymous.  For similar reasons, an object of an
anonymous array type cannot be  renamed.   No  syntactic  form  exists  for
renaming a generic unit.
A subtype can be used to achieve the effect of renaming a type (including a
task type) as in
subtype MODE is TEXT_IO.FILE_MODE;
8.6  \uThe Package Standard\n
The predefined \vtypes\v305. (for example the types BOOLEAN, CHARACTER and INTEGER)
are  the  types  that are declared in a predefined \vpackage\v700. called STANDARD;
this package also includes the \vdeclarations\v301. of their predefined operations.
The package STANDARD is described in Annex C.  Apart  from  the  predefined
numeric  types,  the specification of the package STANDARD \vmust\v108. be the same
for all implementations of the language.
The package STANDARD  forms  a  \vdeclarative  region\v801.  which  encloses  every
\vlibrary  unit\v1001.  and consequently the \vmain program\v1001.;  the declaration of every
library unit is assumed to \voccur  immediately  within\v801.  this  package.   The
\vimplicit  declarations\v301. of library units are assumed to be ordered in such a
way that the scope of a given library unit includes  any  compilation  unit
that  mentions  the given library unit in a \vwith clause\v1002..  However, the only
library units that are visible within  a  given  compilation  unit  are  as
follows:   they  include  the  library units \vnamed\v401. by all with clauses that
apply to the given unit, and moreover, if the given  unit  is  a  \vsecondary\v1001.
\vunit\v1001. of some library unit, they include this library unit.
\uNotes:\n
If  all  \vblock  statements\v507.  of  a  program are named, then the name of each
\vprogram unit\v600. can always be  written  as  an  \vexpanded  name\v404.  starting  with
STANDARD (unless this package is itself hidden).
If  a type is declared in the visible part of a library package, then it is
a consequence of the \vvisibility\v803. rules  that  a  basic  operation  (such  as
\vassignment\v502.)  for  this  type  is  directly visible at places where the type
itself is not visible (whether by selection  or  directly).   However  this
operation  can  only  be  applied  to  operands  that  are  visible and the
declaration of these operands requires the visibility of either the type or
one of its \vsubtypes\v305..
8.7  \uThe Context of Overload Resolution\n
\vOverloading\v610. is defined for \vsubprograms\v600.,  \venumeration  literals\v311.,  \voperators\v411.,
and  single  entries,  and  also  for  the  \voperations\v308. that are inherent in
several \vbasic operations\v308. such as \vassignment\v502., \vmembership tests\v413.,  \vallocators\v421.,
the \vliteral null\v330., \vaggregates\v407., and \vstring literals\v406..
For  overloaded entities, overload resolution determines the actual meaning
that an occurrence of an \videntifier\v203. has, whenever the \vvisibility\v803. rules have
determined that more than one meaning is acceptable at the  place  of  this
occurrence;   overload resolution likewise determines the actual meaning of
an occurrence of an operator or some basic operation.
At such a place all visible \vdeclarations\v301. are considered.  The occurrence is
only \vlegal\v108. if there is exactly one interpretation of  each  constituent  of
the  innermost  complete  context;   a  complete  context  is  one  of  the
following:
-  A declaration.
-  A \vstatement\v500..
-  A \vrepresentation clause\v1301..
When considering possible interpretations of a complete context,  the  only
rules  considered are the syntax rules, the scope and visibility rules, and
the rules of the form described below.
(a)  Any rule that requires a \vname\v401. or \vexpression\v410. to have a certain type, or
to have the same type as another name or expression.
(b)  Any rule that requires the type of a name or expression to be  a  type
of  a certain class;  similarly, any rule that requires a certain type
to be a discrete, integer, real,  universal,  character,  boolean,  or
nonlimited type.
(c)  Any rule that requires a prefix to be appropriate for a certain  type.
(d)  Any rule that specifies a certain type as the result type of  a  basic
operation,  and any rule that specifies that this type is of a certain
class.
(e)  The rules that require the type of an aggregate or string  \vliteral\v406.  to
be  determinable  solely  from the enclosing complete context (see 4.3
and 4.2).  Similarly, the rules that require the type of the prefix of
an attribute, the type of the expression of a \vcase statement\v505.,  or  the
type  of  the  operand  of  a  \vtype  conversion\v419.,  to  be  determinable
independently of the context (see 4.1.4, 5.4, 4.6, and 6.4.1).
(f)  The rules given in section  6.6,  for  the  resolution  of  overloaded
subprogram  calls;   in  section  4.6, for the implicit conversions of
universal expressions;  in section 3.6.1, for  the  interpretation  of
\vdiscrete  ranges\v322.  with bounds having a universal type;  and in section
4.1.3, for the interpretation of an expanded name whose prefix denotes
a subprogram or an accept statement.
Subprogram names used as \vpragma\v210. arguments follow  a  different  rule:   the
pragma can apply to several overloaded subprograms, as explained in section
6.3.2  for  the pragma INLINE, in section 11.7 for the pragma SUPPRESS, and
in section 13.9 for the pragma INTERFACE.
Similarly, the simple names given in context clauses (see  10.1.1)  and  in
\vaddress clauses\v1305. follow different rules.
\uNotes:\n
If  there  is  only one possible interpretation, the identifier denotes the
corresponding entity.  However, this does not mean that the  occurrence  is
necessarily  legal  since other requirements exist which are not considered
for overload resolution;  for example,  the  fact  that  an  expression  is
\vstatic\v422.,  the  parameter  modes,  whether an object is constant, \vconformance\v905.
\vrules\v905.,  forcing  occurrences  for  a  representation   clause,   order   of
elaboration, and so on.
Similarly,  \vsubtypes\v305.  are  not  considered  for  overload  resolution  (the
violation of a constraint does not make a program  illegal  but  raises  an
\vexception\v1100. during program execution).
A \vloop parameter specification\v506. is  a  declaration,  and  hence  a  complete
context.
Rules that require certain constructs to have the same parameter and result
type  profile  fall  under the category (a);  the same holds for rules that
require conformance of  two  constructs  since  conformance  requires  that
corresponding  names  be  given  the  same  meaning  by  the visibility and
overloading rules.
9. \uTasks\n
The execution of a program that does not contain a task is defined in terms
of a sequential execution of its actions, according to the rules  described
in  other  chapters  of this manual.  These actions can be considered to be
executed by a single logical processor.
Tasks are entities whose executions proceed in parallel  in  the  following
sense.   Each  task can be considered to be executed by a logical processor
of  its  own.   Different  tasks  (different  logical  processors)  proceed
independently, except at points where they synchronize.
Some  tasks have entries.  An \ventry\v905. of a task can be called by other tasks.
A task accepts a call  of  one  of  its  entries  by  executing  an  \vaccept\v905.
\vstatement\v905. for the entry.  Synchronization is achieved by \vrendezvous\v905. between
a  task  issuing an entry call and a task accepting the call.  Some entries
have parameters;  entry calls and accept statements for  such  entries  are
the principal means of communicating values between tasks.
The  properties of each task are defined by a corresponding task unit which
consists of a \vtask specification\v901. and a \vtask body\v901..  Task units  are  one  of
the  four  forms  of  \vprogram  unit\v600. of which programs can be composed.  The
other forms are \vsubprograms\v600., \vpackages\v700. and \vgeneric units\v1200..  The properties of
task units,  tasks,  and  entries,  and  the  statements  that  affect  the
interaction   between   tasks  (that  is,  \ventry  call  statements\v905.,  accept
statements, \vdelay statements\v906., \vselect statements\v907., and \vabort statements\v913.)  are
described in this chapter.
Note:
Parallel   tasks  (parallel  logical  processors)  may  be  implemented  on
multicomputers, multiprocessors, or with interleaved execution on a  single
physical  processor.   On  the  other  hand, whenever an implementation can
detect that the same effect can be guaranteed if parts of the actions of  a
given  task  are  executed  by  different  physical  processors  acting  in
parallel, it may choose to execute them in  this  way;   in  such  a  case,
several physical processors implement a single logical processor.
More details:
 9.1     \vTask Specifications and Task Bodies\v901.
 9.2     \vTask Types and Task Objects\v902.
 9.3     \vTask Execution - Task Activation\v903.
 9.4     \vTask Dependence - Termination of Tasks\v904.
 9.5     \vEntries, Entry Calls and Accept Statements\v905.
 9.6     \vDelay Statements, Duration and Time\v906.
 9.7     \vSelect Statements\v907.
 9.8     \vPriorities\v911.
 9.9     \vTask and Entry Attributes\v912.
 9.10    \vAbort Statements\v913.
 9.11    \vShared Variables\v914.
 9.12    \vExample of Tasking\v915.
9.1  \uTask Specifications and Task Bodies\n
A task unit consists of a task specification  and  a  task  body.   A  task
specification  that  starts  with  the \vreserved words\v211.  task \vtype\v305. declares a
task type.  The value of an \vobject\v302. of a task type designates a task  having
the  entries,  if  any, that are declared in the task specification;  these
entries are also called entries of this object.  The execution of the  task
is defined by the corresponding task body.
A  task specification without the reserved word type defines a single task.
A task declaration with this form of specification  is  equivalent  to  the
\vdeclaration\v301.   of  an  anonymous  task  type  immediately  followed  by  the
\vdeclaration of an object\v303. of the task type, and  the  task  unit  \videntifier\v203.
names the object.  In the remainder of this chapter, explanations are given
in  terms  of  task  \vtype declarations\v306.;  the corresponding explanations for
single task declarations follow from the stated equivalence.
    task_declaration ::= task_specification;
    task_specification ::=
       task [type] identifier [is
          {\ventry_declaration\v905.}
          {\vrepresentation_clause\v1301.}
       end [task_simple_name]]
    task_body ::=
        task body task_simple_name is
           [\vdeclarative_part\v333.]
        begin
            sequence_of_statements
       [exception
            exception_handler
           {exception_handler}]
        end [task_simple_name];
The \vsimple name\v401. at the start of a task  body  must  repeat  the  task  unit
identifier.   Similarly  if  a  simple  name appears at the end of the task
specification or body, it must repeat the task unit identifier.   Within  a
task  body,  the  name  of  the corresponding task unit can also be used to
refer to the task object that designates the task currently  executing  the
body;   furthermore,  the  use  of  this name as a type mark is not allowed
within the task unit itself.
For the  \velaboration\v333.  of  a  task  specification,  \ventry\v905.  declarations  and
representation  clauses,  if  any, are elaborated in the order given.  Such
representation clauses only apply to  the  entries  declared  in  the  task
specification (see 13.5).
The  elaboration  of a task body has no other effect than to establish that
the body can from then on be used for the execution of tasks designated  by
objects of the corresponding task type.
The  execution of a task body is invoked by the activation of a task object
of the corresponding type (see 9.3).  The optional  \vexception  handlers\v1102.  at
the end of a task body handle exceptions raised during the execution of the
\vsequence of statements\v501. of the task body (see 11.4).
Examples of specifications of task types:
    task type RESOURCE is
       entry SEIZE;
       entry RELEASE;
    end RESOURCE;
    task type KEYBOARD_DRIVER is
       entry READ (C : out CHARACTER);
       entry WRITE(C : in  CHARACTER);
    end KEYBOARD_DRIVER;
Examples of specifications of single tasks:
    task PRODUCER_CONSUMER is
       entry READ (V : out ITEM);
       entry WRITE(E : in  ITEM);
    end;
    task CONTROLLER is
       entry REQUEST(LEVEL)(D : ITEM);  --  a family of entries
    end CONTROLLER;
    task USER;  --  has no entries
Example of task specification and corresponding body:
    task PROTECTED_ARRAY is
       --  INDEX and ITEM are global types
       entry READ (N : in INDEX; V : out ITEM);
       entry WRITE(N : in INDEX; E : in  ITEM);
    end;
    task body PROTECTED_ARRAY is
       TABLE : \uarray\n(INDEX) of ITEM := (INDEX => NULL_ITEM);
    begin
       loop
          select
             \uaccept\n READ (N : in INDEX; V : out ITEM) do
                V := TABLE(N);
             end READ;
          or
             \uaccept\n WRITE(N : in INDEX; E : in  ITEM) do
                TABLE(N) := E;
             end WRITE;
          end select;
       end loop;
    end PROTECTED_ARRAY;
Note:
A task specification specifies the interface of tasks of the task type with
other  tasks  of  the  same  or  of different types, and also with the \vmain\v1001.
\vprogram\v1001..
9.2  \uTask Types and Task Objects\n
A task type is a \vlimited type\v708..  Hence  neither  \vassignment\v502.  nor
the  predefined  comparison  for  \vequality\v413.  and  \vinequality\v413. are defined for
\vobjects\v302. of task types;  moreover, the mode out is not allowed for a  \vformal\v602.
\vparameter\v602. whose \vtype\v305. is a task type.
A  task object is an object whose type is a task type.  The value of a task
object \vdesignates\v330. a task that has the entries  of  the  corresponding  task
type,  and whose execution is specified by the corresponding \vtask body\v901..  If
a task object is the object, or a \vsubcomponent\v305. of the object,  declared  by
an  \vobject declaration\v303., then the value of the task object is defined by the
\velaboration\v333. of the object declaration.  If a task object is the object,  or
a  subcomponent  of  the object, created by the evaluation of an \vallocator\v421.,
then the value of the task object is  defined  by  the  evaluation  of  the
allocator.   For  all  parameter modes, if an \vactual parameter\v607. designates a
task, the associated formal parameter designates the same task;   the  same
holds  for  a  subcomponent  of  an  actual parameter and the corresponding
subcomponent of the associated formal parameter;  finally, the  same  holds
for generic parameters.
\uExamples:\n
    CONTROL  : RESOURCE;
    TELETYPE : KEYBOARD_DRIVER;
    POOL     : \uarray\n(1 .. 10) of KEYBOARD_DRIVER;
    --  see also examples of declarations of single tasks in 9.1
Example of \vaccess type\v330. designating task objects:
    type KEYBOARD is \uaccess\n KEYBOARD_DRIVER;
    TERMINAL : KEYBOARD := new KEYBOARD_DRIVER;
\uNotes:\n
Since  a  task type is a limited type, it can appear as the definition of a
limited \vprivate type\v704. in a \vprivate part\v702., and as a \vgeneric  actual  parameter\v1206.
associated  with  a  formal parameter whose type is a limited type.  On the
other hand, the type of a \vgeneric formal parameter of mode\v1202. in must not be a
limited type and hence cannot be a task type.
Task objects behave as \vconstants\v303. (a task object always designates the  same
task)  since  their  values are implicitly defined either at declaration or
allocation, or by a \vparameter  association\v606.,  and  since  no  assignment  is
available.   However  the  \vreserved  word\v211.  constant  is  not allowed in the
declaration  of  a  task  object  since  this  would  require  an  explicit
\vinitialization\v303..   A  task object that is a formal parameter of mode in is a
constant (as is any formal parameter of this mode).
If an application needs to store and exchange task identities, it can do so
by defining an access type designating the corresponding task  objects  and
by  using  access  values  for identification purposes (see above example).
Assignment is available for such an access type as for any access type.
\vSubtype declarations\v307. are allowed for task types as  for  other  types,  but
there are no \vconstraints\v305. applicable to task types.
9.3  \uTask Execution - Task Activation\n
A  \vtask body\v901. defines the execution of any task that is designated by a \vtask\v902.
\vobject\v902. of the corresponding \vtask type\v901..  The initial part of this  execution
is  called  the  activation  of  the  task  object,  and  also  that of the
designated task;  it consists of the \velaboration\v333. of the  \vdeclarative  part\v333.,
if  any, of the task body.  The execution of different tasks, in particular
their activation, proceeds in \vparallel\v900..
If an object declaration that declares a  task  object  occurs  immediately
within  a  declarative  part, then the activation of the task object starts
after the elaboration of the declarative part (that is, after  passing  the
reserved  word  begin following the declarative part);  similarly if such a
declaration  occurs  immediately  within  a  package   specification,   the
activation  starts  after  the  elaboration  of the declarative part of the
\vpackage body\v701..  The same holds for the activation of a task object that is a
\vsubcomponent\v305. of an object declared immediately within a declarative part or
package specification.  The first \vstatement\v500. following the declarative  part
is  executed only after conclusion of the activation of these task objects.
Should an \vexception\v1100. be raised by the activation of one of these tasks, that
task becomes a \vcompleted task\v904.;   other  tasks  are  not  directly
affected.   Should  one  of  these  tasks  thus become completed during its
activation, the \vexception TASKING_ERROR\v1101. is raised upon  conclusion  of  the
activation  of  all  of  these  tasks  (whether  successfully or not);  the
exception is raised at  a  place  that  is  immediately  before  the  first
statement  following  the  declarative part (immediately after the reserved
word begin).  Should several of these tasks thus  become  completed  during
their activation, the exception TASKING_ERROR is raised only once.
Should  an  exception be raised by the elaboration of a declarative part or
package  specification,  then  any  task  that  is  created  (directly   or
indirectly)  by  this  elaboration  and  that  is not yet activated becomes
terminated and is therefore  never  activated  (see  section  9.4  for  the
definition of a terminated task).
For  the  above  rules,  in  any  package  body  without statements, a null
statement is assumed.  For any package without a package body, an  implicit
package  body  containing a single null statement is assumed.  If a package
without a package body is declared immediately within some program unit  or
block  statement,  the  implicit  package  body  occurs  at  the end of the
declarative part of the program unit or  block  statement;   if  there  are
several  such  packages,  the  order  of  the  implicit  package  bodies is
undefined.
A task object that is the object, or a subcomponent of the object,  created
by  the  evaluation  of  an \vallocator\v421. is activated by this evaluation.  The
activation starts after any initialization for the object  created  by  the
allocator;   if  several subcomponents are task objects, they are activated
in parallel.  The access value designating such an object  is  returned  by
the allocator only after the conclusion of these activations.
Should an exception be raised by the activation of one of these tasks, that
task  becomes  a  completed  task;   other tasks are not directly affected.
Should one of these tasks thus become completed during its activation,  the
exception  TASKING_ERROR is raised upon conclusion of the activation of all
of these tasks (whether successfully or not);  the exception is  raised  at
the  place where the allocator is evaluated.  Should several of these tasks
thus become completed during their activation, the exception  TASKING_ERROR
is raised only once.
Should  an  exception be raised by the initialization of the object created
by an allocator (hence before  the  start  of  any  activation),  any  task
designated  by  a  subcomponent  of  this  object becomes terminated and is
therefore never activated.
Example:
    procedure P is
       A, B : RESOURCE;  --  elaborate the task objects A, B
       C    : RESOURCE;  --  elaborate the task object C
    begin
       --  the tasks A, B, C are activated in parallel
           before the first statement
       ...
    end;
\uNotes:\n
An \ventry\v905. of a task can be called before the task has  been  activated.   If
several  tasks  are  activated  in  parallel, the execution of any of these
tasks need not await the end of the activation  of the other tasks.  A task
may become completed during its activation either because of  an  exception
or because it is aborted (see 9.10).
9.4  \uTask Dependence - Termination of Tasks\n
Each task depends on at least one master.  A master is a construct that  is
either  a  task,  a currently executing \vblock statement\v507. or subprogram, or a
library package (a \vpackage\v700. declared within another \vprogram unit\v600.  is  not  a
master).   The  dependence  on  a  master  is  a  direct  dependence in the
following two cases:
(a)  The task designated by  a  \vtask  object\v902.  that  is  the  \vobject\v302.,  or  a
     \vsubcomponent\v305.  of the object, created by the evaluation of an \vallocator\v421.
     depends on the master that elaborates the  corresponding  \vaccess  type\v330.
     definition.
(b)  The task designated by any other task object  depends  on  the  master
     whose execution creates the task object.
Furthermore,  if a task depends on a given master that is a block \vstatement\v500.
executed by another master, then  the  task  depends  also  on  this  other
master,  in  an  indirect  manner;  the same holds if the given master is a
subprogram called by another master, and if the given master is a task that
depends (directly or indirectly) on another master.  Dependences exist  for
objects  of  a  private  type  whose full \vdeclaration\v301. is in terms of a task
type.
A task is said to have completed its execution when  it  has  finished  the
execution  of  the  \vsequence  of statements\v501. that appears after the reserved
word  begin in the corresponding body.  Similarly a block or  a  subprogram
is  said to have completed its execution when it has finished the execution
of the corresponding sequence of statements.  For a  block  statement,  the
execution  is also said to be completed when it reaches an \vexit\v508., return, or
\vgoto statement\v510. transferring control out of the block.  For a procedure, the
execution is  also  said  to  be  completed  when  a  corresponding  \vreturn\v509.
\vstatement\v509.  is  reached.   For  a \vfunction\v609., the execution is also said to be
completed after the  evaluation  of  the  result  expression  of  a  return
statement.  Finally the execution of a task, block statement, or subprogram
is  completed if an \vexception\v1100. is raised by the execution of its sequence of
statements and there is no corresponding \vhandler\v1102., or, if there is one, when
it has finished the execution of the corresponding handler.
If a task has no dependent task, its termination takes place  when  it  has
completed  its  execution.   After  its  termination,  a task is said to be
terminated.  If a task has dependent tasks,  its  termination  takes  place
when  the  execution  of  the task is completed and all dependent tasks are
terminated.  A block  statement  or  \vsubprogram  body\v603.  whose  execution  is
completed is not left until all of its dependent tasks are terminated.
Termination  of  a  task otherwise takes place if and only if its execution
has reached an \vopen  terminate  alternative\v908.  in  a  select  statement  (see
9.7.1), and the following conditions are satisfied:
  -  The task depends on some master whose execution  is  completed  (hence
     not a library package).
  -  Each task that depends on the  master  considered  is  either  already
     terminated  or similarly waiting on an open \vterminate alternative\v908. of a
     select statement.
When both conditions are satisfied, the task considered becomes terminated,
together with all tasks that depend on the master considered.
Example:
    declare
       type GLOBAL is \uaccess\n RESOURCE;          --  see 9.1
       A, B : RESOURCE;
       G    : GLOBAL;
    begin
       --  activation of A and B
       declare
          type LOCAL is \uaccess\n RESOURCE;
          X : GLOBAL := new RESOURCE;  --  activation of X.\uall\n
          L : LOCAL  := new RESOURCE;  --  activation of L.\uall\n
          C : RESOURCE;
       begin
          --  activation of C
          G := X;  --  both G and X \vdesignate\v330. the same task object
          ...
       end;  --  await termination of C and L.\uall\n (but not X.\uall\n)
       ...
    end;  --  await termination of A, B, and G.\uall\n
\uNotes:\n
The rules given for termination imply that all tasks that depend  (directly
or  indirectly)  on a given master and that are not already terminated, can
be terminated (collectively) if and only if each of them is waiting  on  an
open  terminate  alternative of a select statement and the execution of the
given master is completed.
The usual rules apply to the \vmain program\v1001..   Consequently,  termination  of
the  main  program  awaits  termination  of  any dependent task even if the
corresponding task type is declared in a library  package.   On  the  other
hand,  termination  of the main program does not await termination of tasks
that depend on library packages;  the language does not define whether such
tasks are required to terminate.
For an access type derived from  another  access  type,  the  corresponding
access  type  definition  is that of the parent type;  the dependence is on
the master that elaborates the ultimate parent access type definition.
A \vrenaming declaration\v805. defines a new name for an existing entity and  hence
creates no further dependence.
9.5  \uEntries, Entry Calls, and Accept Statements\n
Entry calls and accept statements are the primary means of  synchronization
of  \vtasks\v900., and of communicating values between tasks.  An entry declaration
is similar to a \vsubprogram declaration\v601.  and  is  only  allowed  in  a  \vtask\v901.
\vspecification\v901..   The  actions  to  be performed when an entry is called are
specified by corresponding accept statements.
    entry_declaration ::=
       entry identifier [(discrete_range)] [formal_part];
    entry_call_statement ::= entry_name [\vactual_parameter_part\v606.];
    accept_statement ::=
       \uaccept\n entry_simple_name [(entry_index)] [formal_part] [do
          sequence_of_statements
       end [entry_simple_name]];
    entry_index ::= \vexpression\v410.
An entry declaration that includes a \vdiscrete range\v322. declares  a
family  of distinct entries having the same \vformal part\v601. (if any);  that is,
one such entry for each value of the discrete range.  The term single entry
is used in the definition of any rule that applies to any entry other  than
one  of  a family.  The task designated by an \vobject\v302. of a task type has (or
owns) the entries declared in the specification of the task type.
Within the body of a task, each of its single entries or entry families can
be named by the corresponding \vsimple name\v401..  The  \vname\v401.  of  an  entry  of  a
family takes the form of an \vindexed component\v402., the family simple name being
followed  by  the index in parentheses;  the type of this index must be the
same as that of the  discrete  range  in  the  corresponding  entry  family
declaration.   Outside  the  body of a task an entry name has the form of a
\vselected component\v404.,  whose  \vprefix\v401.  denotes  the  task  object,  and  whose
\vselector\v404. is the simple name of one of its single entries or entry families.
A  single  entry overloads a \vsubprogram\v600., an \venumeration literal\v311., or another
single entry if they have the same \videntifier\v203..  \vOverloading\v610. is not  defined
for  entry  families.  A single entry or an entry of an entry family can be
renamed as a \vprocedure\v600. as explained in section 8.5.
The parameter modes defined for parameters of the formal part of  an  entry
declaration  are the same as for a subprogram declaration and have the same
meaning (see 6.2).  The syntax of an entry call  statement  is  similar  to
that   of   a  \vprocedure  call\v606.  statement,  and  the  rules  for  parameter
associations are the same as for subprogram calls (see 6.4.1 and 6.4.2).
An accept statement specifies the actions to be performed at a  call  of  a
named entry (it can be an entry of a family).  The formal part of an accept
statement  must  conform to the formal part given in the declaration of the
single entry or entry family named by the  accept  statement  (see  section
6.3.1  for  the \vconformance rules\v604.).  If a simple name appears at the end of
an accept statement, it must repeat that given at the start.
An accept statement for an entry of a given task is only allowed within the
corresponding \vtask body\v901.;  excluding within the body  of  any  program  unit
that  is,  itself,  inner  to  the task body;  and excluding within another
accept statement for either the same single entry or an entry of  the  same
family.   (One  consequence  of this rule is that a task can execute accept
statements only for its own entries.)  A task body can  contain  more  than
one accept statement for the same entry.
For the \velaboration\v301. of an entry declaration, the discrete range, if any, is
evaluated  and  the  formal  part,  if  any,  is  then  elaborated as for a
subprogram declaration.
Execution of an accept statement starts with the \vevaluation\v411.  of  the  entry
index  (in  the  case of an entry of a family).  Execution of an entry call
statement starts with the evaluation of the entry name;  this  is  followed
by any evaluations required for actual parameters in the same manner as for
a  subprogram call (see 6.4).  Further execution of an accept statement and
of a corresponding entry call statement are synchronized.
If a given entry is called by only one task, there are  two  possibilities:
  -  If  the  calling  task  issues  an  entry  call  statement  before   a
     corresponding  accept  statement  is  reached  by  the task owning the
     entry, the execution of the calling task is suspended.
  -  If a task reaches an accept statement prior to any call of that entry,
     the execution of the task is suspended until such a call is  received.
When an entry has been called and a corresponding accept statement has been
reached,  the  \vsequence  of  statements\v501., if any, of the accept statement is
executed by the called task (while the  calling  task  remains  suspended).
This  interaction is called a rendezvous.  Thereafter, the calling task and
the task owning the entry continue their \vexecution in parallel\v900..
If several  tasks  call  the  same  entry  before  a  corresponding  accept
statement  is reached, the calls are queued;  there is one queue associated
with each entry.  Each execution of an accept statement  removes  one  call
from the queue.  The calls are processed in the order of arrival.
An  attempt  to  call  an  entry of a task that has completed its execution
raises the \vexception TASKING_ERROR\v1101. at the point of the call, in the calling
task;  similarly, this exception is raised at the point of the call if  the
called  \vtask completes\v904.  its  execution before accepting the call (see also
9.10 for the case when the called \vtask becomes  abnormal\v913.).   The  \vexception\v1101.
\vCONSTRAINT_ERROR\v1101.  is  raised  if  the  index of an entry of a family is not
within the specified discrete range.
Examples of entry declarations:
    entry READ(V : out ITEM);
    entry SEIZE;
    entry REQUEST(LEVEL)(D : ITEM);  --  a family of entries
Examples of entry calls:
    CONTROL.RELEASE;                      --  see 9.2 and 9.1
    PRODUCER_CONSUMER.WRITE(E);           --  see 9.1
    POOL(5).READ(NEXT_CHAR);              --  see 9.2 and 9.1
    CONTROLLER.REQUEST(LOW)(SOME_ITEM);   --  see 9.1
Examples of accept statements:
    \uaccept\n SEIZE;
    \uaccept\n READ(V : out ITEM) do
       V := LOCAL_ITEM;
    end READ;
    \uaccept\n REQUEST(LOW)(D : ITEM) do
       ...
    end REQUEST;
\uNotes:\n
The formal part given in an accept statement is not elaborated; it is  only
used to identify the corresponding entry.
An  accept  statement   can  call  subprograms  that issue entry calls.  An
accept statement need not  have  a  sequence  of  statements  even  if  the
corresponding  entry  has  parameters.   Equally, it can have a sequence of
statements even if the corresponding entry has no parameters.  The sequence
of statements of an accept statement can include \vreturn statements\v509..  A task
can call its own entries but it will, of course,  deadlock.   The  language
permits  \vconditional\v909.  and  \vtimed  entry  calls\v910..  The
language rules ensure that a task can only be in one entry queue at a given
time.
If the bounds of  the  discrete  range  of  an  entry  family  are  integer
literals,  the  index (in an entry name or accept statement) must be of the
predefined \vtype INTEGER\v314. (see 3.6.1).
9.6  \uDelay Statements, Duration, and Time\n
The execution of a delay \vstatement\v500. evaluates  the  \vsimple  expression\v410.,  and
suspends  further  execution of the \vtask\v900. that executes the delay statement,
for at least the duration specified by the resulting value.
    delay_statement ::= delay simple_expression;
The simple expression must be of the predefined \vfixed point type\v319.  DURATION;
its value is expressed in seconds;  a delay statement with a negative value
is equivalent to a delay statement with a zero value.
Any  implementation  of  the  type  \vDURATION\v1700.  must  allow representation of
durations (both positive and negative) up to at least  86400  seconds  (one
day);   the  smallest  representable  duration,  DURATION'SMALL must not be
greater than twenty milliseconds (whenever possible, a  value  not  greater
than  fifty  microseconds should be chosen).  Note that DURATION'SMALL need
not correspond to the basic clock cycle, the named number SYSTEM.TICK  (see
13.7).
The  definition  of  the  \vtype\v305.  TIME  is provided in the predefined \vlibrary\v1001.
\vpackage\v700. CALENDAR.  The function CLOCK returns the current value of TIME  at
the  time  it is called.  The functions YEAR, MONTH, DAY and SECONDS return
the corresponding values for a given value of the type TIME;  the procedure
SPLIT returns all four  corresponding  values.   Conversely,  the  function
TIME_OF  combines  a  year  number,  a  month  number,  a day number, and a
duration, into a value of  type  TIME.   The  \voperators\v411.  "+"  and  "-"  for
\vaddition\v411.  and  subtraction  of  times  and  durations,  and  the \vrelational\v411.
\voperators\v411. for times, have the conventional meaning.
The exception TIME_ERROR is raised by the function TIME_OF  if  the  actual
parameters do not form a proper date.  This exception is also raised by the
operators  "+"  and  "-" if, for the given operands, these operators cannot
return a date whose year number  is  in  the  range  of  the  corresponding
subtype, or if the operator "-" cannot return a result that is in the range
of the type DURATION.
    package CALENDAR is
       type TIME is private;
       subtype YEAR_NUMBER  is INTEGER  range 1901 .. 2099;
       subtype MONTH_NUMBER is INTEGER  range 1 .. 12;
       subtype DAY_NUMBER   is INTEGER  range 1 .. 31;
       subtype DAY_DURATION is DURATION range 0.0 .. 86_400.0;
       function CLOCK return TIME;
       function YEAR   (DATE : TIME) return YEAR_NUMBER;
       function MONTH  (DATE : TIME) return MONTH_NUMBER;
       function DAY    (DATE : TIME) return DAY_NUMBER;
       function SECONDS(DATE : TIME) return DAY_DURATION;
       procedure SPLIT (DATE    : in  TIME;
                        YEAR    : out YEAR_NUMBER;
                        MONTH   : out MONTH_NUMBER;
                        DAY     : out DAY_NUMBER;
                        SECONDS : out DAY_DURATION);
       function TIME_OF(YEAR    : YEAR_NUMBER;
                        MONTH   : MONTH_NUMBER;
                        DAY     : DAY_NUMBER;
                        SECONDS : DAY_DURATION := 0.0) return TIME;
       function "+"  (LEFT : TIME;     RIGHT : DURATION) return TIME;
       function "+"  (LEFT : DURATION; RIGHT : TIME)     return TIME;
       function "-"  (LEFT : TIME;     RIGHT : DURATION) return TIME;
       function "-"  (LEFT : TIME;     RIGHT : TIME)     return DURATION;
       function "<"  (LEFT, RIGHT : TIME) return BOOLEAN;
       function "<=" (LEFT, RIGHT : TIME) return BOOLEAN;
       function ">"  (LEFT, RIGHT : TIME) return BOOLEAN;
       function ">=" (LEFT, RIGHT : TIME) return BOOLEAN;
       TIME_ERROR : exception;  --  can be raised by TIME_OF, "+", and "-"
    private
       -- implementation-dependent
    end;
\uExamples:\n
    delay 3.0;  --  delay 3.0 seconds
    declare
       use CALENDAR;
       --  INTERVAL is a global constant of type DURATION
       NEXT_TIME : TIME := CLOCK + INTERVAL;
    begin
       loop
          delay NEXT_TIME - CLOCK;
          --  some actions
          NEXT_TIME := NEXT_TIME + INTERVAL;
       end loop;
    end;
\uNotes:\n
The second example causes the loop to be repeated every INTERVAL seconds on
average.    This   interval  between  two  successive  iterations  is  only
approximate.  However, there will be no cumulative drift  as  long  as  the
duration of each iteration is (sufficiently) less than INTERVAL.
9.7  \uSelect Statements\n
There  are three forms of select statements.  One form provides a \vselective\v908.
\vwait\v908. for one or more alternatives.  The other two provide  conditional  and
timed entry calls.
    select_statement ::= selective_wait
       | \vconditional_entry_call\v909. | \vtimed_entry_call\v910.
More details:
 9.7.1   \vSelective Waits\v908.
 9.7.2   \vConditional Entry Calls\v909.
 9.7.3   \vTimed Entry Calls\v910.
9.7.1  \uSelective Waits\n
This form of the \vselect statement\v907. allows a combination of waiting for,  and
selecting  from,  one  or  more  alternatives.  The selection can depend on
\vconditions\v504. associated with each alternative of the selective wait.
    selective_wait ::=
        select
          select_alternative
       {or
          select_alternative}
       [else
          \vsequence_of_statements\v501.]
        end select;
    select_alternative ::=
       [when condition =>]
          selective_wait_alternative
    selective_wait_alternative ::= accept_alternative
       | delay_alternative | terminate_alternative
    accept_alternative ::= accept_statement [sequence_of_statements]
    delay_alternative  ::= \vdelay_statement\v906.  [sequence_of_statements]
    terminate_alternative ::= terminate;
A selective wait must contain at least one accept alternative.  In addition
a selective wait can contain either a terminate alternative (only one),  or
one or more delay alternatives, or an else part;  these three possibilities
are mutually exclusive.
A  select alternative is said to be open if it does not start with when and
a condition, or if the  condition  is  TRUE.   It  is  said  to  be  closed
otherwise.
For  the execution of a selective wait, any conditions specified after when
are evaluated in some order that is not  defined  by  the  language;   open
alternatives are thus determined.  For an open delay alternative, the \vdelay\v906.
\vexpression\v906.  is  also  evaluated.  Similarly, for an open accept alternative
for an \ventry\v905. of a family, the \ventry index\v905. is also evaluated.  Selection and
execution of one open alternative, or of the else part, then completes  the
execution  of  the  selective  wait;   the  rules  for  this  selection are
described below.
Open accept alternatives are  first  considered.   Selection  of  one  such
alternative  takes  place  immediately  if  a  corresponding  \vrendezvous\v905. is
possible, that is, if there is a corresponding \ventry call\v905. issued by another
\vtask\v900. and waiting to be accepted.   If  several  alternatives  can  thus  be
selected,  one  of them is selected arbitrarily (that is, the language does
not  define  which  one).   When  such  an  alternative  is  selected,  the
corresponding  \vaccept  statement\v905.  and  possible  subsequent  statements are
executed.  If no rendezvous is immediately possible and there  is  no  else
part,  the  task  waits  until  an  open  selective wait alternative can be
selected.
Selection of the other forms of alternative or of an else part is performed
as follows:
  -  An open delay alternative will be selected if  no  accept  alternative
     can  be  selected before the specified delay has elapsed (immediately,
     for a negative or zero delay in the absence of  \vqueued  entry  calls\v905.);
     any  subsequent  statements  of the alternative are then executed.  If
     several delay alternatives can thus be selected (that is, if they have
     the same delay), one of them is selected arbitrarily.
  -  The else part is selected and its statements are executed if no accept
     alternative  can  be  immediately  selected,  in  particular,  if  all
     alternatives are closed.
  -  An open terminate alternative is selected if the conditions stated  in
     section  9.4 are satisfied.  It is a consequence of other rules that a
     terminate alternative cannot be selected while there is a queued entry
     call for any entry of the task.
The \vexception PROGRAM_ERROR\v1101. is raised if all alternatives  are  closed  and
there is no else part.
Examples of a select statement:
    select
       \uaccept\n DRIVER_AWAKE_SIGNAL;
    or
       delay 30.0*SECONDS;
       STOP_THE_TRAIN;
    end select;
Example of a task body with a select statement:
    task body RESOURCE is
       BUSY : BOOLEAN := FALSE;
    begin
       loop
          select
             when not BUSY =>
                \uaccept\n SEIZE do
                   BUSY := TRUE;
                end;
          or
             \uaccept\n RELEASE do
                BUSY := FALSE;
             end;
          or
             terminate;
          end select;
       end loop;
    end RESOURCE;
\uNotes:\n
A  selective  wait  is  allowed to have several open delay alternatives.  A
selective wait is allowed to have several open accept alternatives for  the
same entry.
9.7.2  \uConditional Entry Calls\n
A conditional entry call issues an entry call that is then  canceled  if  a
\vrendezvous\v905. is not immediately possible.
    conditional_entry_call ::=
       select
           \ventry_call_statement\v905.
          [sequence_of_statements]
       else
           sequence_of_statements
       end select;
For  the  execution  of  a  conditional entry call, the entry name is first
evaluated.  This  is  followed  by  any  \vevaluations\v411.  required  for  actual
parameters as in the case of a subprogram call (see 6.4).
The  entry  call  is  canceled  if the execution of the called \vtask\v900. has not
reached a point where it is ready to accept the call (that  is,  either  an
\vaccept statement\v905. for the corresponding entry, or a \vselect statement\v907. with an
open  accept alternative for the entry), or if there are prior \vqueued entry\v905.
\vcalls\v905. for this entry.  If the called task has reached a  select  statement,
the  entry  call is canceled if an accept alternative for this entry is not
selected.
If the entry call  is  canceled,  the  statements  of  the  else  part  are
executed.   Otherwise,  the  rendezvous  takes  place;   and  the  optional
\vsequence of statements\v501. after the entry call is then executed.
The  execution  of  a  conditional  entry   call   raises   the   \vexception\v1101.
\vTASKING_ERROR\v1101.  if  the called task has already completed its execution (see
also 9.10 for the case when the called \vtask becomes abnormal\v913.).
Example:
    procedure SPIN(R : RESOURCE) is
    begin
       loop
          select
             R.SEIZE;
             return;
          else
             \unull\n;  --  busy waiting
          end select;
       end loop;
    end;
9.7.3  \uTimed Entry Calls\n
A timed entry call issues an entry call that is canceled if a \vrendezvous\v905. is
not started within a given delay.
    timed_entry_call ::=
       select
           \ventry_call_statement\v905.
          [sequence_of_statements]
       or
           delay_alternative
       end select;
For the execution of a timed entry call, the entry name is first evaluated.
This is followed by any \vevaluations\v411. required for \vactual  parameters\v606.  as  in
the  case of a subprogram call (see 6.4).  The \vexpression\v410. stating the delay
is then evaluated, and the entry call is finally issued.
If  a  rendezvous  can  be  started  within  the  specified  \vduration\v906.   (or
immediately,  as  for  a  \vconditional  entry  call\v909.,  for a negative or zero
delay), it is performed and the optional \vsequence of statements\v501.  after  the
entry  call  is  then executed.  Otherwise, the entry call is canceled when
the specified duration has expired, and the optional sequence of statements
of the delay alternative is executed.
The execution of a timed entry call raises the \vexception  TASKING_ERROR\v1101.  if
the called \vtask completes\v904. its execution before accepting the call (see also
9.10 for the case when the called \vtask becomes abnormal\v913.).
Example:
    select
       CONTROLLER.REQUEST(MEDIUM)(SOME_ITEM);
    or
       delay 45.0;
       --  controller too busy, try something else
    end select;
9.8  \uPriorities\n
Each  \vtask\v900.  may  (but  need  not)  have a priority, which is a value of the
\vsubtype\v305. PRIORITY (of the \vtype INTEGER\v314.) declared in the  predefined  library
\vpackage  SYSTEM\v1308..   A  lower  value indicates a lower degree of
urgency;  the range of priorities is implementation-defined.  A priority is
associated with a task if a \vpragma\v210.
    pragma PRIORITY (\vstatic_expression\v422.);
appears in the corresponding \vtask specification\v901.;  the priority is given  by
the  value  of  the  expression.   A  priority  is associated with the \vmain\v1001.
\vprogram\v1001. if such a pragma appears in its  outermost  \vdeclarative  part\v333..   At
most  one such pragma can appear within a given task specification or for a
subprogram that is a library unit, and these are the  only  allowed  places
for  this  pragma.   A  pragma  PRIORITY  has  no  effect if it occurs in a
subprogram other than the main program.
The specification of a priority  is  an  indication  given  to  assist  the
implementation  in the allocation of processing resources to parallel tasks
when there are more tasks eligible for  execution  than  can  be  supported
simultaneously  by  the  available  processing  resources.   The  effect of
priorities on scheduling is defined by the following rule:
     If two tasks with different priorities are both eligible for execution
     and could sensibly be executed using the same physical processors  and
     the  same  other processing resources, then it cannot be the case that
     the task with the lower priority is executing while the task with  the
     higher priority is not.
For  tasks of the same priority, the scheduling order is not defined by the
language.  For tasks without explicit priority, the  scheduling  rules  are
not  defined,  except  when such tasks are engaged in a \vrendezvous\v905..  If the
priorities  of  both  tasks  engaged  in  a  rendezvous  are  defined,  the
rendezvous  is executed with the higher of the two priorities.  If only one
of the two priorities is defined, the rendezvous is executed with at  least
that  priority.   If  neither is defined, the priority of the rendezvous is
undefined.
\uNotes:\n
The priority of a  task  is  static  and  therefore  fixed.   However,  the
priority  during  a  rendezvous  is  not  necessarily  static since it also
depends on the priority of the task calling the entry.   Priorities  should
be  used  only to indicate relative degrees of urgency;  they should not be
used for task synchronization.
9.9  \uTask and Entry Attributes\n
For a \vtask object\v902. or value T the following \vattributes\v405. are defined:
T'CALLABLE    Yields the  value  \vFALSE\v313.  when  the  execution  of  the  \vtask\v900.
              designated  by  T  is either \vcompleted\v904. or \vterminated\v904., or when
              the \vtask is abnormal\v913..  Yields the value \vTRUE\v313. otherwise.   The
              value of this attribute is of the predefined \vtype BOOLEAN\v313..
T'TERMINATED  Yields the  value  TRUE  if  the  task  \vdesignated\v901.  by  T  is
              terminated.   Yields the value FALSE otherwise.  The value of
              this attribute is of the predefined type BOOLEAN.
In addition, the representation attributes STORAGE_SIZE, SIZE, and  ADDRESS
are defined for a task object T or a \vtask type\v901. T (see 13.7.2).
The  attribute COUNT is defined for an \ventry\v905. E of a task unit T.  The entry
can be either a single entry or an entry of a family (in  either  case  the
name  of  the  single  entry  or  entry family can be either a simple or an
expanded name).  This attribute is only allowed within the body of  T,  but
excluding  within any program unit that is, itself, inner to the body of T.
E'COUNT       Yields the number of entry  calls  presently  \vqueued\v905.  on  the
              entry E (if the attribute is evaluated by the execution of an
              \vaccept  statement\v905. for the entry E, the count does not include
              the calling task).  The value of this  attribute  is  of  the
              \vtype universal_integer\v314..
Note:
Algorithms  interrogating  the attribute E'COUNT should take precautions to
allow for the increase of the value of this attribute  for  incoming  entry
calls, and its decrease, for example with \vtimed entry calls\v910..
9.10  \uAbort Statements\n
An  abort  statement  causes  one  or  more  \vtasks\v900. to become abnormal, thus
preventing any further \vrendezvous\v905. with such tasks.
    abort_statement ::= \uabort\n task_name {, task_name};
The determination of the type of each task name uses the fact that the type
of the \vname\v401. is a task type.
For the execution of an abort \vstatement\v500., the given task names are \vevaluated\v401.
in some order that is not defined by the language.  Each  named  task  then
becomes abnormal unless it is already \vterminated\v904.;  similarly, any task that
depends  on  a named task becomes abnormal unless it is already terminated.
Any abnormal task whose execution is suspended at an  \vaccept  statement\v905.,  a
\vselect  statement\v907.,  or  a  \vdelay statement\v906. becomes completed;  any abnormal
task whose execution is suspended at an entry call, and that is not yet  in
a corresponding rendezvous, becomes completed and is removed from the entry
\vqueue\v905.;   any  abnormal task that has not yet started its \vactivation\v903. becomes
completed (and hence also terminated).  This completes the execution of the
abort statement.
The completion of any other abnormal task need not happen before completion
of the abort statement.  It must happen no later  than  when  the  abnormal
task  reaches a synchronization point that is one of the following: the end
of its activation;  a point where it causes the activation of another task;
an entry call; the start or the end  of  an  accept  statement;   a  select
statement;   a  delay  statement;   an  \vexception  handler\v1102.;   or  an  abort
statement.  If a task that calls an  entry  becomes  \vabnormal  while  in  a\v1107.
\vrendezvous\v1107.,  its  termination  does not take place before the completion of
the rendezvous (see 11.5).
The call of an entry of an abnormal task raises the \vexception TASKING_ERROR\v1101.
at the place of the call.  Similarly, the exception TASKING_ERROR is raised
for any task that has called an entry of an abnormal  task,  if  the  entry
call  is still queued or if the rendezvous is not yet finished (whether the
entry call is an \ventry call statement\v905., or  a  \vconditional\v909.  or  \vtimed  entry\v910.
\vcall\v910.);   the  exception  is  raised  no  later  than  the completion of the
abnormal task.  The value of the \vattribute CALLABLE\v912. is \vFALSE\v313. for  any  task
that is abnormal (or completed).
If  the  abnormal completion of a task takes place while the task updates a
variable, then the value of this variable is undefined.  Example:
    \uabort\n USER, TERMINAL.\uall\n, POOL(3);
\uNotes:\n
An abort statement should be  used  only  in  extremely  severe  situations
requiring  unconditional termination.  A task is allowed to abort any task,
including itself.
9.11  \uShared Variables\n
The normal means of communicating values between tasks is  by  \ventry  calls\v905.
and \vaccept statements\v905..
If  two  \vtasks\v900.  read  or  update  a  shared  \vvariable\v303.  (that is, a variable
accessible by both), then neither of them may  assume  anything  about  the
order  in  which  the  other  performs its operations, except at the points
where they synchronize.  Two tasks are synchronized at the start and at the
end of their \vrendezvous\v905..  At the start and at the end of its \vactivation\v903.,  a
task  is  synchronized  with  the task that causes this activation.  A task
that has completed its execution is synchronized with any other task.
For the actions performed by a program  that  uses  shared  variables,  the
following assumptions can always be made:
  -  If between two synchronization points of a task,  this  task  reads  a
     shared  variable  whose  \vtype\v305.  is  a  scalar  or access type, then the
     variable is not updated by any other task at any  time  between  these
     two points.
  -  If between two synchronization points of a task, this task  updates  a
     shared  variable  whose  type  is  a  scalar  or access type, then the
     variable is neither read nor updated by any other  task  at  any  time
     between these two points.
The  execution  of  the program is \verroneous\v108. if any of these assumptions is
violated.
If a given task \vreads the value\v602. of a shared variable, the above assumptions
allow an implementation to maintain local copies of the value (for example,
in registers or in some other form of temporary storage);  and for as  long
as  the  given task neither reaches a synchronization point nor \vupdates the\v602.
\vvalue\v602. of the shared variable, the above assumptions  imply  that,  for  the
given  task,  reading  a  local  copy  is  equivalent to reading the shared
variable itself.
Similarly, if a given task updates the value  of  a  shared  variable,  the
above  assumptions  allow an implementation to maintain a local copy of the
value, and to defer the effective store of the local copy into  the  shared
variable until a synchronization point, provided that every further read or
update  of the variable by the given task is treated as a read or update of
the local copy.  On the other hand, an implementation  is  not  allowed  to
introduce  a  store,  unless  this  store  would  also  be  executed in the
\vcanonical order\v1108..
The \vpragma\v210. SHARED can be used to specify that every read  or  update  of  a
variable  is a synchronization point for that variable;  that is, the above
assumptions always hold for the given variable  (but  not  necessarily  for
other variables).  The form of this pragma is as follows:
    pragma SHARED(variable_simple_name);
This  pragma  is  allowed  only  for  a  variable  declared  by  an  object
declaration and whose type is  a  scalar  or  access  type;   the  variable
declaration  and  the  pragma  must  both occur (in this order) immediately
within the same \vdeclarative part\v333. or \vpackage specification\v701.;  the pragma must
appear before any occurrence of the name of the variable, other than in  an
address clause.
An  implementation must restrict the objects for which the pragma SHARED is
allowed to objects for which each of direct reading and direct updating  is
implemented as an indivisible operation.
9.12  \uExample of Tasking\n
The following example defines a buffering task to smooth variations between
the  speed  of  output  of  a producing task and the speed of input of some
consuming  task.   For  instance,  the  producing  task  may  contain   the
statements
    loop
       --  produce the next character CHAR
       BUFFER.WRITE(CHAR);
       exit when CHAR = ASCII.EOT;
    end loop;
and the consuming task may contain the statements
    loop
       BUFFER.READ(CHAR);
       --  consume the character CHAR
       exit when CHAR = ASCII.EOT;
    end loop;
The  buffering  task contains an internal pool of characters processed in a
round-robin fashion.  The pool has two indices, an  IN_INDEX  denoting  the
space  for the next input character and an OUT_INDEX denoting the space for
the next output character.
    task BUFFER is
       entry READ (C : out CHARACTER);
       entry WRITE(C : in  CHARACTER);
    end;
    task body BUFFER is
       POOL_SIZE : constant INTEGER := 100;
       POOL      : \uarray\n(1 .. POOL_SIZE) of CHARACTER;
       COUNT     : INTEGER range 0 .. POOL_SIZE := 0;
       IN_INDEX, OUT_INDEX : INTEGER range 1 .. POOL_SIZE := 1;
    begin
       loop
          select
             when COUNT < POOL_SIZE =>
                \uaccept\n WRITE(C : in CHARACTER) do
                   POOL(IN_INDEX) := C;
                end;
                IN_INDEX := IN_INDEX mod POOL_SIZE + 1;
                COUNT    := COUNT + 1;
          or when COUNT > 0 =>
                \uaccept\n READ(C : out CHARACTER) do
                   C := POOL(OUT_INDEX);
                end;
                OUT_INDEX := OUT_INDEX mod POOL_SIZE + 1;
                COUNT     := COUNT - 1;
          or
             terminate;
          end select;
       end loop;
    end BUFFER;
:1000
10. \uProgram Structure and Compilation Issues\n
The   overall  structure  of  programs  and  the  facilities  for  separate
\vcompilation\v1001. are described in this chapter.  A program is  a  collection  of
one  or  more  \vcompilation  units\v1001.  submitted  to  a compiler in one or more
compilations.  Each compilation unit specifies the separate compilation  of
a  construct  which  can  be  a  \vsubprogram  declaration\v601. or \vbody\v603., a \vpackage\v701.
\vdeclaration  or  body\701.,  a  \vgeneric  declaration\v1201.  or  \vbody\v1205.,  or  a   \vgeneric\v1206.
\vinstantiation\v1206..   Alternatively  this  construct  can be a \vsubunit\v1004., in which
case it includes the body of a subprogram, package, \vtask unit\v900.,  or  generic
unit declared within another compilation unit.
More details:
 10.1    \vCompilation Units - Library Units\v1001.
 10.2    \vSubunits of Compilation Units\v1004.
 10.3    \vOrder of Compilation\v1006.
 10.4    \vThe Program Library\v1007.
 10.5    \vElaboration of Library Units\v1008.
 10.6    \vProgram Optimization\v1009.
:1001
10.1  \uCompilation Units - Library Units\n
The text of a program can be submitted to  the  compiler  in  one  or  more
compilations.  Each compilation is a succession of compilation units.
    compilation ::= {compilation_unit}
    compilation_unit ::=
         \vcontext_clause\v1002. \vlibrary_unit\v1008. | context_clause secondary_unit
    library_unit ::=
         subprogram_declaration | \vpackage_declaration\v701.
       | \vgeneric_declaration\v1201.    | \vgeneric_instantiation\v1206.
       | subprogram_body
    secondary_unit ::= library_unit_body | \vsubunit\v1004.
    library_unit_body ::= subprogram_body | \vpackage_body\v701.
The compilation units of a program are said to belong to a program library.
A  compilation  unit  defines either a library unit or a secondary unit.  A
secondary unit is either the separately compiled \vproper body\v333. of  a  library
unit,  or  a  subunit  of  another  compilation  unit.  The \vdesignator\v601. of a
separately compiled \vsubprogram\v600. (whether a library unit or a  subunit)  \vmust\v108.
be an \videntifier\v203..  Within a program library the simple \vnames\v401. of all library
units must be distinct identifiers.
The effect of compiling a library unit is to define (or redefine) this unit
as one that belongs to the program library.  For the \vvisibility\v803. rules, each
library  unit  acts  as  a  \vdeclaration\v301.  that \voccurs immediately within\v801. the
\vpackage STANDARD\v806..
The effect of compiling a secondary unit is to define the body of a library
unit, or in the case of a subunit, to define the proper body of  a  \vprogram\v600.
\vunit\v600. that is declared within another compilation unit.
A \vsubprogram body\v603. given in a compilation unit is interpreted as a secondary
unit  if  the  program  library  already  contains a library unit that is a
subprogram with the same name;  it  is  otherwise  interpreted  both  as  a
library  unit  and  as  the  corresponding library unit body (that is, as a
secondary unit).
The compilation units of a compilation are compiled in the given order.   A
\vpragma\v210.  that  applies  to the whole of a compilation must appear before the
first compilation unit of that compilation.
A subprogram that is a library unit can be used as a main  program  in  the
usual sense.  Each main program acts as if called by some \venvironment\v1007. \vtask\v900.;
the  means  by  which this execution is initiated are not prescribed by the
language definition.  An implementation may impose certain requirements  on
the  parameters  and  on  the  result,  if  any,  of  a main program (these
requirements  must  be  stated  in  Appendix  F).   In  any   case,   every
implementation  is  required  to  \vallow\v108.,  at  least, main programs that are
parameterless \vprocedures\v601., and every main program must be a subprogram  that
is a library unit.
\uNotes:\n
A  simple  program may consist of a single compilation unit.  A compilation
need not have any compilation units;  for example, its text can consist  of
pragmas.
The  designator  of  a library function cannot be an \voperator symbol\v601., but a
\vrenaming declaration\v805.  is  allowed  to  rename  a  library  function  as  an
\voperator\v411..   Two  library  subprograms  must  have distinct simple names and
hence cannot overload  each  other.   However,  renaming  declarations  are
allowed  to  define  overloaded  names  for such subprograms, and a locally
declared subprogram is allowed  to  overload  a  library  subprogram.   The
expanded  name STANDARD.L can be used for a library unit L (unless the name
STANDARD is hidden) since library units  act  as  declarations  that  occur
immediately within the package STANDARD.
More details:
 10.1.1  \vContext Clauses - With Clauses\v1002.
 10.1.2  \vExamples of Compilation Units\v1003.
:1002
10.1.1  \uContext Clauses - With Clauses\n
A context clause is used to specify  the  \vlibrary  units\v1001.  whose  \vnames\v401.  are
needed within a \vcompilation unit\v1001..
    context_clause ::= {with_clause {use_clause}}
    with_clause ::= with unit_simple_name {, unit_simple_name};
The  names  that  appear  in  a  context clause \vmust\v108. be the \vsimple names\v401. of
library units.  The simple name of any library unit  is  \vallowed\v108.  within  a
with  clause.   The  only names allowed in a \vuse clause\v804. of a context clause
are the simple names of library \vpackages\v700. mentioned by previous with clauses
of the context clause.  A simple name declared by a renaming declaration is
not allowed in a context clause.
The with clauses and use clauses of the context clause of  a  library  unit
apply  to this library unit and also to the \vsecondary unit\v1001. that defines the
corresponding body (whether such a clause  is  repeated  or  not  for  this
unit).   Similarly,  the with clauses and use clauses of the context clause
of a compilation unit apply to this unit and also to its \vsubunits\v1004., if  any.
If  a  library unit is named by a with clause that applies to a compilation
unit, then this library unit is directly  visible  within  the  compilation
unit,  except  where  hidden;   the  library unit is visible as if declared
immediately within the \vpackage STANDARD\v806..
Dependences among compilation units are defined by with clauses;  that  is,
a  compilation  unit  that mentions other library units in its with clauses
depends on those library units.  These dependences between units are  taken
into account for the determination of the allowed order of compilation (and
recompilation)  of compilation units, as explained in section 10.3, and for
the determination of the allowed order of \velaboration\v333. of compilation units,
as explained in section 10.5.
\uNotes:\n
A library unit named by a with clause of  a  compilation  unit  is  visible
(except  where hidden) within the compilation unit and hence can be used as
a corresponding \vprogram unit\v600..  Thus within the compilation unit,  the  name
of  a  library  package can be given in use clauses and can be used to form
expanded names;  a library subprogram can be called;  and  \vinstances\v1206.  of  a
library \vgeneric unit\v1201. can be declared.
The  rules given for with clauses are such that the same effect is obtained
whether the name of a library unit is mentioned once or more than  once  by
the applicable with clauses, or even within a given with clause.
Example 1 : A \vmain program\v1001.:
The  following  is  an  example  of  a  main program consisting of a single
compilation unit:  a \vprocedure\v601. for printing the real roots of  a  quadratic
equation.   The  predefined  package  TEXT_IO  and  a  user-defined package
REAL_OPERATIONS (containing the definition of the  \vtype\v305.  REAL  and  of  the
packages  REAL_IO  and REAL_FUNCTIONS) are assumed to be already present in
the program library.  Such packages may be used by other main programs.
    with TEXT_IO, REAL_OPERATIONS; use REAL_OPERATIONS;
    procedure QUADRATIC_EQUATION is
       A, B, C, D : REAL;
       use REAL_IO,         --  achieves \vdirect visibility\v803. of GET and PUT
                                for REAL
           TEXT_IO,         --  achieves direct visibility of PUT for strings
                                and of NEW_LINE
           REAL_FUNCTIONS;  --  achieves direct visibility of SQRT
    begin
       GET(A); GET(B); GET(C);
       D := B**2 - 4.0*A*C;
       if D < 0.0 then
          PUT("Imaginary Roots.");
       else
          PUT("Real Roots : X1 = ");
          PUT((-B - SQRT(D))/(2.0*A)); PUT(" X2 = ");
          PUT((-B + SQRT(D))/(2.0*A));
       end if;
       NEW_LINE;
    end QUADRATIC_EQUATION;
Notes on the example:
The with clauses of a compilation unit need only mention the names of those
library subprograms and packages whose  \vvisibility\v803.  is  actually  necessary
within  the  unit.   They  need  not (and should not) mention other library
units that are used in turn by some of the units named in the with clauses,
unless these other library units are also  used  directly  by  the  current
compilation unit.  For example, the body of the package REAL_OPERATIONS may
need elementary operations provided by other packages.  The latter packages
should  not  be  named by the with clause of QUADRATIC_EQUATION since these
elementary operations are not directly called within its body.
:1003
10.1.2  \uExamples of Compilation Units\n
A  \vcompilation  unit\v1001.  can be split into a number of compilation units.  For
example, consider the following \vprogram\v1000..
    procedure PROCESSOR is
       SMALL : constant := 20;
       TOTAL : INTEGER  := 0;
       package STOCK is
          LIMIT : constant := 1
          TABLE : \uarray\n (1 .. LIMIT) of INTEGER;
          procedure RESTART;
       end STOCK;
       \vpackage body\v701. STOCK is
          procedure RESTART is
          begin
             for N in 1 .. LIMIT loop
                TABLE(N) := N;
             end loop;
          end;
       begin
          RESTART;
       end STOCK;
       procedure UPDATE(X : INTEGER) is
          use STOCK;
       begin
          ...
          TABLE(X) := TABLE(X) + SMALL;
          ...
       end UPDATE;
    begin
       ...
       STOCK.RESTART;  -- reinitializes TABLE
       ...
    end PROCESSOR;
The following three compilation units  define  a  program  with  an  effect
equivalent to the above example (the broken lines between compilation units
serve  to remind the reader that these units need not be contiguous texts).
Example 2 : Several compilation units:
    package STOCK is
       LIMIT : constant := 1
       TABLE : \uarray\n (1 .. LIMIT) of INTEGER;
       procedure RESTART;
    end STOCK;
    -------------------------------------------------
    package body STOCK is
       procedure RESTART is
       begin
          for N in 1 .. LIMIT loop
             TABLE(N) := N;
          end loop;
       end;
    begin
       RESTART;
    end STOCK;
    -------------------------------------------------
    with STOCK;
    procedure PROCESSOR is
       SMALL : constant := 20;
       TOTAL : INTEGER  := 0;
       procedure UPDATE(X : INTEGER) is
          use STOCK;
       begin
          ...
          TABLE(X) := TABLE(X) + SMALL;
          ...
       end UPDATE;
    begin
       ...
       STOCK.RESTART;  --  reinitializes TABLE
       ...
    end PROCESSOR;
Note that in the latter version, the \vpackage\v700. STOCK  has  no  \vvisibility\v803.  of
outer  \videntifiers\v203.  other  than  the predefined identifiers (of the package
STANDARD).  In particular, STOCK does not use any  identifier  declared  in
PROCESSOR  such  as  SMALL  or  TOTAL;  otherwise STOCK could not have been
extracted from PROCESSOR in the above manner.  The procedure PROCESSOR,  on
the  other  hand,  depends  on  STOCK  and  mentions this package in a \vwith\v1002.
\vclause\v1002..  This permits the inner occurrences of STOCK in the  expanded  name
STOCK.RESTART and in the \vuse clause\v804..
These three compilation units can be submitted in one or more compilations.
For  example,  it  is  possible to submit the \vpackage specification\v701. and the
package body together and in this order in a single compilation.
:1004
10.2  \uSubunits of Compilation Units\n
A subunit is used for the \vseparate compilation\v1001. of  the  proper  body  of  a
\vprogram  unit\v600.  declared  within  another  \vcompilation unit\v1001..  This method of
splitting a \vprogram\v1000. permits hierarchical program development.
    body_stub ::=
         \vsubprogram_specification\v601. is separate;
       | \vpackage body\701. package_simple_name is separate;
       | \vtask body\901. task_simple_name is separate;
    subunit ::=
         separate (parent_unit_name) proper_body
A body stub is only allowed as the body of a program unit (a subprogram,  a
\vpackage\v700.,  a  \vtask  unit\v901.,  or  a  \vgeneric  unit\v1200.)  if  the  body  stub \voccurs\v801.
\vimmediately within\v801. either the specification of a  library  package  or  the
\vdeclarative part\v333. of another compilation unit.
If the body of a program unit is a body stub, a separately compiled subunit
containing  the  corresponding  proper  body is required.  In the case of a
subprogram, the subprogram specifications given in the \vproper body\v333.  and  in
the body stub must \vconform\v604..
Each subunit mentions the \vname\v401. of its parent unit, that is, the compilation
unit  where  the corresponding body stub is given.  If the parent unit is a
\vlibrary unit\v1001., it is called the ancestor library unit.  If the  parent  unit
is  itself  a  subunit,  the  parent  unit name must be given in full as an
\vexpanded name\v404., starting with the \vsimple name\v401. of the ancestor library  unit.
The  simple  names of all subunits that have the same ancestor library unit
must be distinct \videntifiers\v203..
\vVisibility\v803. within the proper body of a subunit is the visibility that would
be obtained at the place of the corresponding body stub (within the  parent
unit)  if  the \vwith clauses\v1002. and \vuse clauses\v804. of the subunit were appended to
the \vcontext clause\v1002. of the parent unit.  If the  parent  unit  is  itself  a
subunit,  then  the  same  rule is used to define the visibility within the
proper body of the parent unit.
The effect of the \velaboration\v333. of a body stub is  to  elaborate  the  proper
body of the subunit.
\uNotes:\n
Two  subunits  of  different library units in the same program library need
not have distinct identifiers.  In any case, their full expanded names  are
distinct,  since  the  simple names of library units are distinct and since
the simple names of all subunits that have a given library unit as ancestor
unit are also distinct.  By  means  of  renaming  \vdeclarations\v301.,  overloaded
\vsubprogram\v600. names that rename (distinct) subunits can be introduced.
A  library unit that is named by the with clause of a subunit can be hidden
by a declaration (with the same identifier) given in the proper body of the
subunit.  Moreover, such a library unit can even be \vhidden by a declaration\v803.
given within a parent unit since a library unit  acts  as  if  declared  in
STANDARD;   this  however  does  not  affect the interpretation of the with
clauses themselves, since only names of library units can  appear  in  with
clauses.
More details:
 10.2.1  \vExamples of Subunits\v1005.
:1005
10.2.1  \uExamples of Subunits\n
The  \vprocedure\v600. TOP is first written as a \vcompilation unit\v1001. without subunits.
    with TEXT_IO;
    procedure TOP is
       type REAL is digits 10;
       R, S : REAL := 1.0;
       \vpackage\v700. FACILITY is
          PI : constant := 3.14159_26536;
          function  F(X : REAL) return REAL;
          procedure G(Y, Z : REAL);
       end FACILITY;
       \vpackage body\v701. FACILITY is
          --  some \vlocal declarations\v801. followed by
          function F(X : REAL) return REAL is
          begin
             --  sequence of statements of F
             ...
          end F;
          procedure G(Y, Z : REAL) is
             --  local procedures using TEXT_IO
             ...
          begin
             --  sequence of statements of G
             ...
          end G;
       end FACILITY;
       procedure TRANSFORM(U : in out REAL) is
          use FACILITY;
       begin
          U := F(U);
          ...
       end TRANSFORM;
    begin -- TOP
       TRANSFORM(R);
       ...
       FACILITY.G(R, S);
    end TOP;
The body of the package FACILITY and that of the procedure TRANSFORM can be
made into separate subunits of TOP.  Similarly, the body of the procedure G
can be made into a subunit of FACILITY as follows.
Example 3:
    procedure TOP is
       type REAL is digits 10;
       R, S : REAL := 1.0;
       package FACILITY is
          PI : constant := 3.14159_26536;
          function  F(X : REAL) return REAL;
          procedure G(Y, Z : REAL);
       end FACILITY;
     package body FACILITY is separate;                -- stub of FACILITY
     procedure TRANSFORM(U : in out REAL) is separate; -- stub of TRANSFORM
    begin  --  TOP
       TRANSFORM(R);
       ...
       FACILITY.G(R, S);
    end TOP;
    -------------------------------------------------
    separate (TOP)
    procedure TRANSFORM(U : in out REAL) is
       use FACILITY;
    begin
       U := F(U);
       ...
    end TRANSFORM;
    -------------------------------------------------
    separate (TOP)
    package body FACILITY is
       --  some local declarations followed by
       function F(X : REAL) return REAL is
       begin
          --  sequence of statements of F
          ...
       end F;
       procedure G(Y, Z : REAL) is separate;              -- stub of G
    end FACILITY;
    -------------------------------------------------
    with TEXT_IO;
    separate (TOP.FACILITY)  --  full name of FACILITY
    procedure G(Y, Z : REAL) is
       --  local procedures using TEXT_IO
       ...
    begin
       --  sequence of statements of G
       ...
    end G;
In the above example TRANSFORM and FACILITY are subunits of TOP, and G is a
subunit of FACILITY.  The \vvisibility\v803. in the split version is the same as in
the initial version except for one change:   since  TEXT_IO  is  only  used
within  G,  the  corresponding  \vwith clause\v1002. is written for G instead of for
TOP.   Apart  from  this  change,  the  same  \videntifiers\v203.  are  visible  at
corresponding  program points in the two versions.  For example, all of the
following  are (directly) visible within the \vproper body\v333. of the subunit  G:
the  procedure  TOP,  the  \vtype\v305.  REAL,  the  \vvariables\v303. R and S, the package
FACILITY and the contained \vnamed number\v302. PI and \vsubprograms\v600. F and G.
:1006
10.3  \uOrder of Compilation\n
The  rules  defining  the  order  in which units can be compiled are direct
consequences of the \vvisibility\v803. rules and, in particular, of the  fact  that
any  \vlibrary  unit\v1001. that is mentioned by the \vcontext clause\v1002. of a \vcompilation\v1001.
unit is visible in the \vcompilation unit\v1001..
A compilation unit must be compiled after all library units  \vnamed\v401.  by  its
context clause.  A \vsecondary unit\v1001. that is a subprogram or \vpackage body\v701. must
be  compiled after the corresponding library unit.  Any \vsubunit\v1004. of a parent
compilation unit must be compiled after the parent compilation unit.
If any error is detected while attempting to compile  a  compilation  unit,
then  the attempted compilation is rejected and it has no effect whatsoever
on the program library;  the same holds for recompilations (no  compilation
unit can become obsolete because of such a recompilation).
The  order in which the compilation units of a program are compiled must be
consistent with the partial ordering defined by the above rules.
Similar rules apply for recompilations.  A compilation unit is  potentially
affected  by  a  change in any library unit named by its context clause.  A
secondary unit is potentially affected by a  change  in  the  corresponding
library  unit.   The  subunits of a parent compilation unit are potentially
affected by a change of the parent compilation unit.  If a compilation unit
is successfully recompiled, the compilation units potentially  affected  by
this  change  are obsolete and must be recompiled unless they are no longer
needed.  An implementation may be able to reduce the compilation  costs  if
it  can deduce that some of the potentially affected units are not actually
affected by the change.
The subunits of a unit can be recompiled without affecting the unit itself.
Similarly, changes in a subprogram or \vpackage  body\v701.  do  not  affect  other
compilation  units  (apart  from  the  subunits  of  the  body) since these
compilation  units  only  have  access  to  the   subprogram   or   package
specification.  An implementation is only allowed to deviate from this rule
for  inline inclusions, for certain compiler optimizations, and for certain
implementations of generic program units, as described below.
  -  If a \vpragma INLINE\v605. is applied to a \vsubprogram declaration\v601. given  in  a
     \vpackage  specification\v701.,  inline inclusion will only be achieved if the
     package body is compiled before units calling the subprogram.  In such
     a case, inline inclusion creates a dependence of the calling  unit  on
     the  package  body,  and  the compiler  must recognize this dependence
     when deciding on the need for recompilation.  If  a  calling  unit  is
     compiled  before  the  package  body, the pragma may be ignored by the
     compiler for such calls (a  warning  that  inline  inclusion  was  not
     achieved may be issued).  Similar considerations apply to a separately
     compiled subprogram for which an INLINE pragma is specified.
  -  For optimization purposes, an implementation may compile several units
     of a given compilation in a way that creates further dependences among
     these   compilation   units.    The  compiler  must  then  take  these
     dependences into account when deciding on the need for recompilations.
  -  An implementation may require  that  a  \vgeneric  declaration\v1201.  and  the
     corresponding \vproper body\v333. be part of the same compilation, whether the
     generic  unit  is  itself  separately  compiled or is local to another
     compilation unit.  An implementation may also require that subunits of
     a \vgeneric unit\v1200. be part of the same compilation.
Examples of Compilation Order:
(a)  In example 1 (see 10.1.1):  The \vprocedure\v601. QUADRATIC_EQUATION  must  be
     compiled after the library packages TEXT_IO  and REAL_OPERATIONS since
     they appear in its \vwith clause\v1002..
(b)  In example 2 (see 10.1.2):  The package body STOCK  must  be  compiled
     after the corresponding package specification.
(c)  In example 2 (see 10.1.2):  The specification  of  the  package  STOCK
     must  be  compiled before the procedure PROCESSOR.  On the other hand,
     the procedure PROCESSOR can be compiled either  before  or  after  the
     package body STOCK.
(d)  In example 3 (see 10.2.1):  The procedure G must be compiled after the
     package  TEXT_IO  since this package is named by the with clause of G.
     On the other hand, TEXT_IO can be compiled either before or after TOP.
(e)  In example 3 (see 10.2.1):  The subunits TRANSFORM and  FACILITY  must
     be compiled after the main program TOP.  Similarly, the subunit G must
     be compiled after its \vparent unit\v1004. FACILITY.
\uNotes:\n
For  library  packages,  it  follows  from  the  recompilation rules that a
package body is made obsolete by the  recompilation  of  the  corresponding
specification.   If  the  new  package specification is such that a package
body is not required (that  is,  if  the  package  specification  does  not
contain  the  declaration  of  a program unit), then the recompilation of a
body for this package is not required.  In any case, the  obsolete  package
body  must  not  be  used  and  can  therefore  be deleted from the program
library.
:1007
10.4  \uThe Program Library\n
Compilers are required to enforce the language rules in the same manner for
a  program  consisting of several \vcompilation units\v1001. (and \vsubunits\v1004.) as for a
program submitted as a single compilation.  Consequently,  a  library  file
containing information on the compilation units of the program library must
be  maintained  by the compiler or compiling environment.  This information
may include symbol tables and other information  pertaining to the order of
previous compilations.
A normal submission to the compiler consists of the compilation unit(s) and
the library file.  The latter is used for checks and is  updated  for  each
compilation unit successfully compiled.
\uNotes:\n
A  single  \vprogram\v1001.  library  is  implied  for  the  compilation  units of a
compilation.  The possible existence of different \vprogram libraries\v1001. and the
means by which they are named are not concerns of the language  definition;
they are concerns of the programming environment.
There  should  be  commands  for  creating  the  program library of a given
program or of a given family of programs.  These commands  may  permit  the
reuse  of  units  of  other  program  libraries.   Finally, there should be
commands for interrogating the status of the units of  a  program  library.
The form of these commands is not specified by the language definition.
:1008
10.5  \uElaboration of Library Units\n
Before  the  execution  of  a main program, all \vlibrary units\v1001. needed by the
main program are elaborated, as well  as  the  corresponding  library  unit
bodies,  if  any.  The library units needed by the main program are:  those
\vnamed\v401. by with clauses applicable to the \vmain program\v1001., to its body,  and  to
its  \vsubunits\v1004.;   those  named  by  \vwith clauses\v1002. applicable to these library
units themselves, to the corresponding library unit bodies,  and  to  their
subunits;  and so on, in a transitive manner.
The  \velaboration\v333.  of  these  library units and of the corresponding library
unit bodies is performed in an order consistent with the  partial  ordering
defined  by  the  with  clauses  (see  10.3).   In addition, a library unit
mentioned by the \vcontext clause\v1002. of a subunit must be elaborated before  the
body of the ancestor library unit of the subunit.
An  order of elaboration that is consistent with this partial ordering does
not always ensure that each library unit  body  is  elaborated  before  any
other \vcompilation unit\v1001. whose elaboration necessitates that the library unit
body  be  already  elaborated.   If  the  prior elaboration of library unit
bodies is needed, this can be requested by a \vpragma\v210. ELABORATE.  The form of
this pragma is as follows:
    pragma ELABORATE (library_unit_simple_name {, library_unit_simple_name});
These pragmas are only \vallowed\v108. immediately after the context  clause  of  a
compilation  unit  (before  the subsequent library unit or \vsecondary unit\v1001.).
Each \vargument of such a pragma\v210. must be the \vsimple name\v401. of  a  library  unit
mentioned  by the context clause, and this library unit must have a library
unit body.  Such a pragma specifies that the  library  unit  body  must  be
elaborated  before  the  given  compilation unit.  If the given compilation
unit is a subunit, the library unit body must be elaborated before the body
of the ancestor library unit of the subunit.
The program is \villegal\v108. if no consistent order can be found (that is,  if  a
circularity  exists).   The  elaboration  of  the  compilation units of the
program is performed \vin some order\v108. that is otherwise  not  defined  by  the
language.
:1009
10.6  \uProgram Optimization\n
Optimization  of  the  elaboration  of  \vdeclarations\v301.  and  the execution of
\vstatements\v500. may be performed by compilers.  In particular, a compiler may be
able to optimize a \vprogram\v1000. by evaluating certain \vexpressions\v410.,  in  addition
to  those  that  are  \vstatic expressions\v422..  Should one of these expressions,
whether static or not, be such that an \vexception\v1100. would  be  raised  by  its
\vevaluation\v411.,  then  the  code in that path of the program can be replaced by
code to raise the exception;  the same holds for exceptions raised  by  the
evaluation of names and simple expressions.  (See also section 11.6.)
A  compiler  may  find  that  some  statements or \vsubprograms\v600. will never be
executed, for example, if their execution depends on a \vcondition\v504.  known  to
be FALSE.  The corresponding object machine code can then be omitted.  This
rule permits the effect of conditional compilation within the language.
Note:
An  expression  whose  evaluation  is  known to raise an exception need not
represent an error if it occurs in a statement or subprogram that is  never
executed.  The compiler may warn the programmer of a potential error.
:1100
11. \uExceptions\n
This  chapter  defines  the  facilities  for  dealing  with \verrors\v108. or other
exceptional  situations  that  arise  during  program  execution.   Such  a
situation  is  called  an  exception.   To raise an exception is to abandon
normal program execution so as to draw  attention  to  the  fact  that  the
corresponding situation has arisen.  Executing some actions, in response to
the arising of an exception, is called handling the exception.
An  exception  declaration  declares a \vname\v401. for an exception.  An exception
can be raised by a  \vraise  statement\v1103.,  or  it  can  be  raised  by  another
statement  or  operation  that \vpropagates the exception\v1105..  When an exception
arises, control can be transferred to a user-provided \vexception handler\v1102.  at
the  end  of  a  \vblock statement\v507. or at the end of the body of a \vsubprogram\v603.,
\vpackage\v701., or task unit.
More details:
 11.1    \vException Declarations\v1101.
 11.2    \vException Handlers\v1102.
 11.3    \vRaise Statements\v1103.
 11.4    \vException Handling\v1104.
 11.5    \vExceptions Raised During Task Communication\v1107.
 11.6    \vExceptions and Optimization\v1108.
 11.7    \vSuppressing Checks\v1109.
:1101
11.1  \uException Declarations\n
An exception \vdeclaration\v301. declares a \vname\v401. for an \vexception\v1100..  The name of  an
exception  can  only  be  used in \vraise statements\v1103., \vexception handlers\v1102., and
renaming declarations.
    exception_declaration ::= identifier_list : exception;
An exception declaration  with  several  \videntifiers\v203.  is  equivalent  to  a
sequence  of  single  exception  declarations, as explained in section 3.2.
Each  single  exception  declaration  declares  a  name  for  a   different
exception.   In  particular,  if  a  \vgeneric  unit\v1200.  includes  an  exception
declaration, the exception \vdeclarations implicitly\v1206. generated  by  different
\vinstantiations\v1206.  of  the  generic unit refer to distinct exceptions (but all
have  the  same  identifier).   The  particular  exception  denoted  by  an
exception name is determined at compilation time and is the same regardless
of  how  many  times the exception declaration is elaborated.  Hence, if an
exception declaration occurs in a recursive \vsubprogram\v600., the exception  name
denotes the same exception for all invocations of the recursive subprogram.
The  following  exceptions are predefined in the language;  they are raised
when the situations described are detected.
CONSTRAINT_ERROR  This  exception  is  raised  in  any  of  the   following
                  situations:    upon   an   attempt  to  violate  a  \vrange\v310.
                  \vconstraint\v310.,  an  \vindex  constraint\v322.,  or  a   \vdiscriminant\v327.
                  \vconstraint\v327.;   upon  an  attempt to use a \vrecord component\v325.
                  that does not exist for the current discriminant  values;
                  and  upon  an  attempt  to  use  a \vselected component\v404., an
                  \vindexed component\v402., a \vslice\v403., or an attribute, of an \vobject\v302.
                  designated by an \vaccess value\v330., if  the  object  does  not
                  exist because the \vaccess value is null\v330..
   NUMERIC_ERROR  This exception is raised by the execution of a predefined
                  \vnumeric  operation\v315.  that  cannot deliver a correct result
                  (within the declared  accuracy  for  \vreal  types\v316.);   this
                  includes   the   case  where  an  implementation  uses  a
                  predefined   numeric   operation   for   the   execution,
                  evaluation,  or \velaboration\v333. of some construct.  The rules
                  given in section 4.5.7  define  the  cases  in  which  an
                  implementation  is  not  required to raise this exception
                  when such an error situation arises;   see  also  section
                  11.6.
   PROGRAM_ERROR  This exception is  raised  upon  an  attempt  to  call  a
                  subprogram, to \vactivate a task\v903., or to elaborate a \vgeneric\v1206.
                  \vinstantiation\v1206.,  if the body of the corresponding unit has
                  not yet been elaborated.  This exception is  also  raised
                  if the end of a function is reached (see 6.5);  or during
                  the  execution of a \vselective wait\v908. that has no else part,
                  if this execution determines that  all  alternatives  are
                  closed   (see   9.7.1).    Finally,   depending   on  the
                  implementation, this exception  may  be  raised  upon  an
                  attempt  to  execute an action that is \verroneous\v108., and for
                  \vincorrect order dependences\v108..
   STORAGE_ERROR  This  exception  is  raised  in  any  of  the   following
                  situations:  when the dynamic storage allocated to a \vtask\v900.
                  is  exceeded;   during the evaluation of an \vallocator\v421., if
                  the space  available  for  the  \vcollection\v330.  of  allocated
                  objects  is  exhausted;   or  during the elaboration of a
                  declarative item, or during the execution of a subprogram
                  call, if storage is not sufficient.
   TASKING_ERROR  This exception is raised  when  exceptions  arise  during
                  intertask communication (see 9 and 11.5).
Note:
The  situations described above can arise without raising the corresponding
exceptions, if the pragma SUPPRESS has been used to give permission to omit
the corresponding checks (see 11.7).
Examples of user-defined exception declarations:
    SINGULAR : exception;
    ERROR    : exception;
    OVERFLOW, UNDERFLOW : exception;
:1102
11.2  \uException Handlers\n
The  response  to  one  or  more  \vexceptions\v1100.  is  specified by an exception
handler.
    exception_handler ::=
       \uwhen\n exception_choice {| exception_choice} =>
          \vsequence_of_statements\v501.
    exception_choice ::= exception_name | others
An exception handler occurs in a construct that is either a \vblock statement\v507.
or the body of a \vsubprogram\v603., \vpackage\v701., \vtask unit\v900., or \vgeneric unit\v1201..   Such  a
construct  will be called a frame in this chapter.  In each case the syntax
of a frame that has exception handlers includes the following part:
    \ubegin\n
        sequence_of_statements
    \uexception\n
        exception_handler
       {exception_handler}
    \uend\n
The exceptions denoted by the exception names given as exception choices of
a frame must all be distinct.  The exception choice others is only  allowed
for the last exception handler of a frame and as its only exception choice;
it  stands for all exceptions not listed in previous handlers of the frame,
including exceptions whose \vnames\v401. are  not  visible  at  the  place  of  the
exception handler.
The  exception handlers of a frame handle exceptions that are raised by the
execution of the sequence of  statements  of  the  frame.   The  exceptions
handled  by  a given exception handler are those named by the corresponding
exception choices.
Example:
    \ubegin\n
       --  sequence of statements
    \uexception\n
       \uwhen\nSINGULAR | NUMERIC_ERROR =>
          PUT(" MATRIX IS SINGULAR ");
       \uwhen others\n =>
          PUT(" FATAL ERROR ");
          \uraise\n ERROR;
    end;
Note:
The same kinds of \vstatement\v500. are allowed in the sequence  of  statements  of
each  exception handler as are allowed in the sequence of statements of the
frame.   For example, a \vreturn statement\v509. is allowed in a handler  within  a
\vfunction body\v603..
:1103
11.3  \uRaise Statements\n
A raise statement raises an \vexception\v1100..
    raise_statement ::= raise [exception_name];
For the execution of a raise statement with an exception  \vname\v401.,  the  named
exception  is  raised.  A raise statement without an exception name is only
allowed within an  exception  handler  (but  not  within  the  \vsequence  of\v501.
\vstatements\v501.  of  a \vsubprogram\v600., \vpackage\v700., \vtask unit\v900., or \vgeneric unit\v1200., enclosed
by the handler);  it raises again the exception that caused transfer to the
innermost enclosing handler.
\uExamples:\n
    \uraise\n SINGULAR;
    \uraise\n NUMERIC_ERROR;  --  explicitly raising a predefined exception
    \uraise\n;                --  only within an exception handler
:1104
11.4  \uException Handling\n
When  an  \vexception\v1100.  is  raised,  normal program execution is abandoned and
control is transferred to an \vexception  handler\v1102..   The  selection  of  this
handler  depends on whether the exception is raised during the execution of
\vstatements\v500. or during the \velaboration of declarations\v301..
More details:
 11.4.1  \vExceptions Raised During the Execution of Statements\v1105.
 11.4.2  \vExceptions Raised During the Elaboration of Declarations\v1106.
:1105
11.4.1  \uExceptions Raised During the Execution of Statements\n
The  handling  of  an  \vexception\v1100.  raised  by the execution of a \vsequence of\v501.
\vstatements\v501. depends on whether the innermost frame or \vaccept statement\v905.  that
encloses the sequence of \vstatements\v500. is a \vframe\v1102. or an accept statement.  The
case  where  an accept statement is innermost is described in section 11.5.
The case where a frame is innermost is presented here.
Different actions take place, depending on whether or not this frame has  a
handler  for  the  exception, and on whether the exception is raised in the
sequence of statements of the frame or in that of an \vexception handler\v1102..
If an exception is raised in the sequence of statements of a frame that has
a handler for the exception, execution of the sequence of statements of the
frame is abandoned and control is transferred  to  the  exception  handler.
The  execution  of  the sequence of statements of the handler completes the
execution of the frame (or its \velaboration\v301. if the frame is a \vpackage body\v701.).
If an exception is raised in the sequence of statements  of  a  frame  that
does  not  have  a handler for the exception, execution of this sequence of
statements is abandoned.  The next action depends  on  the  nature  of  the
frame:
(a)  For a \vsubprogram body\v603., the same exception is raised again at the point
     of  \vcall  of the subprogram\v606., unless the \vsubprogram\v600. is the \vmain program\v1001.
     itself, in which case execution of the main program is abandoned.
(b)  For a \vblock statement\v507., the same exception is raised again  immediately
     after  the  block  statement  (that is, within the innermost enclosing
     frame or accept statement).
(c)  For a package body that is a \vdeclarative item\v333., the same  exception  is
     raised  again  immediately  after  this  declarative  item (within the
     enclosing \vdeclarative part\v333.). If the package body is that of a \vsubunit\v1004.,
     the exception is raised again at the place of the  corresponding  \vbody\v1004.
     \vstub\v1004..  If the \vpackage\v700. is a \vlibrary unit\v1001., execution of the main program
     is abandoned.
(d)  For a \vtask body\v901., the \vtask\v900. becomes completed.
An exception that is raised again (as in the above cases (a), (b), and (c))
is  said  to  be propagated, either by the execution of the subprogram, the
execution of the block statement, or the elaboration of the  package  body.
No  propagation  takes place in the case of a task body.  If the frame is a
subprogram or a  block  statement  and  if  it  has  \vdependent  tasks\v904.,  the
propagation  of  an  exception  takes  place  only after termination of the
dependent tasks.
Finally, if an exception is raised in the  sequence  of  statements  of  an
exception  handler,  execution of this sequence of statements is abandoned.
Subsequent actions (including propagation, if any) are as in the cases  (a)
to (d) above, depending on the nature of the frame.
Example:
    function FACTORIAL (N : POSITIVE) return FLOAT is
    \ubegin\n
       \uif\n N = 1 \uthen\n
          \ureturn\n 1.0;
       \uelse\n
          \ureturn\n FLOAT(N) * FACTORIAL(N-1);
       \uend if\n;
    \uexception\n
       \uwhen\n NUMERIC_ERROR => \ureturn\n FLOAT'SAFE_LARGE;
    \uend\n FACTORIAL;
If  the  multiplication  raises  NUMERIC_ERROR,  then  FLOAT'SAFE_LARGE  is
returned by the handler.   This  value  will  cause  further  \vNUMERIC_ERROR\v1101.
\vexceptions\v1101.  to be raised by the evaluation of the expression in each of the
remaining invocations of the function, so that for large values  of  N  the
function will ultimately return the value FLOAT'SAFE_LARGE.
Example:
    \vprocedure\v601. P is
       ERROR : \uexception\n;
       \uprocedure\n R;
       \uprocedure\n Q is
       \ubegin\n
          R;
          ...            --  error situation (2)
       \uexception\n
          ...
          \uwhen\n ERROR =>  --  handler E2
          ...
       \uend\n Q;
       \uprocedure\n R is
       \ubegin\n
          ...            --  error situation (3)
       \uend\n R;
    \ubegin\n
       ...               --  error situation (1)
       Q;
       ...
    \uexception\n
       ...
       \uwhen\n ERROR =>     --  handler E1
       ...
    \uend\n P;
The following situations can arise:
(1)  If the exception ERROR is raised in the sequence of statements of  the
     outer  procedure  P,  the  handler  E1  provided  within  P is used to
     complete the execution of P.
(2)  If the exception ERROR is raised in the sequence of statements  of  Q,
     the  handler E2 provided within Q is used to complete the execution of
     Q.  Control will be returned to the point of call of Q upon \vcompletion\v904.
     of the handler.
(3)  If the exception ERROR is raised in the body of R, called  by  Q,  the
     execution  of  R  is abandoned and the same exception is raised in the
     body of Q.  The handler E2 is then used to complete the  execution  of
     Q, as in situation (2).
Note  that  in  the  third  situation, the exception raised in R results in
(indirectly) transferring control to a handler that is part of Q and  hence
not  enclosed by R.  Note also that if a handler were provided within R for
the exception choice others, situation (3) would cause  execution  of  this
handler, rather than direct termination of R.
Lastly,  if ERROR had been declared in R, rather than in P, the handlers E1
and E2  could  not  provide  an  explicit  handler  for  ERROR  since  this
identifier would not be visible within the bodies of P and Q.  In situation
(3), the exception could however be handled in Q by providing a handler for
the exception choice others.
\uNotes:\n
The  language  does  not define what happens when the execution of the main
program is abandoned after an unhandled exception.
The predefined exceptions are those that can be  propagated  by  the  \vbasic\v308.
\voperations\v308. and the \vpredefined operators\v411..
The  case of a frame that is a \vgeneric unit\v1200. is already covered by the rules
for subprogram and package bodies, since the sequence of statements of such
a frame is not executed but is the template for the corresponding sequences
of  statements  of  the  subprograms  or  packages  obtained   by   \vgeneric\v1206.
\vinstantiation\v1206..
:1106
11.4.2  \uExceptions Raised During the Elaboration of Declarations\n
If an \vexception\v1100. is raised during the \velaboration\v301. of the \vdeclarative part\v333. of
a given \vframe\v1102., this elaboration is abandoned.  The next action  depends  on
the nature of the frame:
(a)  For a \vsubprogram body\v603., the same exception is raised again at the point
     of  \vcall  of the subprogram\v606., unless the \vsubprogram\v600. is the \vmain program\v1001.
     itself, in which case execution of the main program is abandoned.
(b)  For a \vblock statement\v507., the same exception is raised again  immediately
     after the block statement.
(c)  For a \vpackage body\v701. that is a \vdeclarative item\v333., the same  exception  is
     raised again immediately after this declarative item, in the enclosing
     declarative  part.   If  the  package  body  is that of a \vsubunit\v1004., the
     exception is raised again at the place of the corresponding \vbody stub\v1004..
     If the package is a \vlibrary unit\v1001., execution of  the  main  program  is
     abandoned.
(d)  For a \vtask  body\v901.,  the  \vtask  becomes  completed\v904.,  and  the  \vexception\v1101.
     \vTASKING_ERROR\v1101.  is  raised  at  the point of \vactivation\v903. of the \vtask\v900., as
     explained in section 9.3.
Similarly, if an exception is raised during the  elaboration  of  either  a
\vpackage  declaration\v701.  or a \vtask declaration\v901., this elaboration is abandoned;
the next action depends on the nature of the declaration.
(e)  For a package declaration or a task declaration, that is a declarative
     item, the exception is raised again immediately after the  declarative
     item  in the enclosing declarative part or \vpackage specification\v701..  For
     the declaration of a  library  package,  the  execution  of  the  main
     program is abandoned.
An  exception that is raised again (as in the above cases (a), (b), (c) and
(e)) is said to be propagated, either by the execution of the subprogram or
block statement, or by the elaboration of  the  package  declaration,  task
declaration or package body.
Example of an exception in the declarative part of a block statement (case
(b)):
    \uprocedure\n P \uis\n
       ...
    \ubegin\n
       declare
          N : INTEGER := F;  --  the function F may raise ERROR
       \ubegin\n
          ...
       \uexception\n
          \uwhen\n ERROR =>      --  handler E1
       \uend\n ;
       ...
    \uexception\n
       \uwhen\n ERROR =>         --  handler E2
    \uend\nP;
    --  if the exception ERROR is raised in the declaration of N, it is
        handled by E2
:1107
11.5  \uExceptions Raised During Task Communication\n
An  \vexception\v1100.  can  be propagated to a task communicating, or attempting to
communicate, with another \vtask\v900..  An exception can also be propagated  to  a
calling task if the exception is raised during a \vrendezvous\v905..
When  a task calls an entry of another task, the \vexception TASKING_ERROR\v1101. is
raised in the calling task, at the place of the call, if the called task is
completed before accepting the \ventry call\v905. or is already  completed  at  the
time of the call.
A rendezvous can be completed abnormally in two cases:
(a)  When an exception is  raised  within  an  \vaccept  statement\v905.,  but  not
     handled  within  an  inner  \vframe\v1102..  In this case, the execution of the
     accept statement is abandoned and the same exception is  raised  again
     immediately  after  the  accept  statement within the called task; the
     exception is also propagated to the calling task at the point  of  the
     entry call.
(b)  When the task containing the accept statement is completed  abnormally
     as  the  result  of  an  \vabort statement\v913..  In this case, the exception
     TASKING_ERROR is raised in the calling task at the point of the  entry
     call.
On the other hand, if a task issuing an entry call becomes abnormal (as the
result  of  an  abort statement) no exception is raised in the called task.
If the rendezvous has not yet started, the entry call is cancelled.  If the
rendezvous is in progress, it completes normally, and the  called  task  is
unaffected.
:1108
11.6  \uExceptions and Optimization\n
The purpose of this section is to specify the  conditions  under  which  an
implementation  is  allowed  to  perform  certain actions either earlier or
later than specified by other rules of the language.
In general, when the language rules specify an order  for  certain  actions
(the  canonical order), an implementation may only use an alternative order
if it can guarantee that the effect of the program is not  changed  by  the
reordering.   In particular, no \vexception\v1100. should arise for the execution of
the reordered program if none arises for the execution of  the  program  in
the canonical order.  When, on the other hand, the order of certain actions
is   not   defined   by  the  language,  any  order  can  be  used  by  the
implementation.  (For example, the arguments of a \vpredefined  operator\v411.  can
be  evaluated  in  any   order  since the rules given in section 4.5 do not
require a specific order of evaluation.)
Additional freedom is left to  an  implementation  for  reordering  actions
involving  predefined  operations  that  are either predefined operators or
\vbasic operations\v308. other than \vassignments\v502..  This freedom is left, as  defined
below,  even in the case where the execution of these predefined operations
may \vpropagate a (predefined) exception\v1104.:
(a)  For the purpose of establishing whether the same effect is obtained by
     the  execution  of  certain  actions  in  the  canonical  and  in   an
     alternative  order,  it  can  be  assumed  that none of the predefined
     operations  invoked  by  these  actions  propagates   a   (predefined)
     exception, provided that the two following requirements are met by the
     alternative  order:   first,  an  operation must not be invoked in the
     alternative order if  it  is  not  invoked  in  the  canonical  order;
     second,  for  each  operation, the innermost enclosing \vframe\v1102. or \vaccept\v905.
     \vstatement\v905. must be  the  same  in  the  alternative  order  as  in  the
     canonical order, and the same \vexception handlers\v1102. must apply.
(b)  Within an expression, the association of operators  with  operands  is
     specified  by  the  syntax.   However,  for  a  sequence of predefined
     operators of  the  same  precedence  level  (and  in  the  absence  of
     parentheses  imposing  a  specific  association),  any  association of
     operators with operands is  allowed  if  it  satisfies  the  following
     requirement:   an  integer  result  must be equal to that given by the
     canonical left-to-right order;  a  real  result  must  belong  to  the
     result  model  interval  defined for the canonical left-to-right order
     (see 4.5.7).  Such a reordering is allowed even if it  may  remove  an
     exception, or introduce a further predefined exception.
Similarly,  additional  freedom  is  left  to  an  implementation  for  the
evaluation  of  numeric  simple  expressions.   For  the  evaluation  of  a
predefined  operation, an implementation is allowed to use the operation of
a type that has a range wider than that of the \vbase type\v305. of  the  operands,
provided  that  this  delivers  the  exact  result  (or a result within the
declared \vaccuracy\v418., in the case of a \vreal type\v316.), even if  some  intermediate
results   lie   outside   the  range  of  the  base  type.   The  \vexception\v1101.
\vNUMERIC_ERROR\v1101. need not be raised in such a case.   In  particular,  if  the
numeric  expression  is an operand of a predefined relational operator, the
exception NUMERIC_ERROR need  not  be  raised  by  the  evaluation  of  the
relation, provided that the correct BOOLEAN result is obtained.
A preedefined  operation  need  not be invoked at all, if its only possible
effect is to propagate a predefined  exception.   Similarly,  a  predefined
operation  need  not  be invoked if the removal of subsequent operations by
the above rule renders this invocation ineffective.
\uNotes:\n
Rule (b) applies to predefined  operators  but  not  to  the  short-circuit
control forms.
The  expression  SPEED  <  300_000.0  can  be replaced by TRUE if the value
300_000.0 lies outside the base type of SPEED,  even  though  the  implicit
\vconversion\v419.  of the numeric literal would raise the exception NUMERIC_ERROR.
Example:
    declare
       N : INTEGER;
    \ubegin\n
       N := 0;               --  (1)
       \ufor\n J \uin\n 1 .. 10 \uloop\n
          N := N + J**A(K);  --  A and K are global variables
       \uend loop\n;
       PUT(N);
    \uexception\n
       \uwhen others\n => PUT("Some error arose"); PUT(N);
    \uend\n;
The evaluation of A(K) may be  performed  before  the  loop,  and  possibly
immediately before the assignment statement (1) even if this evaluation can
raise  an exception.  Consequently, within the exception handler, the value
of N is either the undefined initial value or a value later  assigned.   On
the  other  hand, the evaluation of A(K) cannot be moved before begin since
an exception would then be  handled  by  a  different  handler.   For  this
reason, the initialization of N in the declaration itself would exclude the
possibility of having an undefined initial value of N in the handler.
:1109
11.7  \uSuppressing Checks\n
The  presence of a SUPPRESS \vpragma\v210. gives permission to an implementation to
omit certain run-time checks.  The form of this pragma is as follows:
    pragma SUPPRESS(identifier [, [ON =>] name]);
The \videntifier\v203. is that of the check that can  be  omitted.   The  name  (if
present)  must  be  either  a  \vsimple  name\v401. or an \vexpanded name\v404. and it must
denote either an \vobject\v302., a \vtype\v305. or \vsubtype\v305., a \vtask unit\v900., or a \vgeneric unit\v1200.;
alternatively the name can be a subprogram name, in which case it can stand
for several visible overloaded \vsubprograms\v600..
A pragma SUPPRESS is only allowed immediately within a \vdeclarative part\v333.  or
immediately  within  a \vpackage specification\v701..  In the latter case, the only
allowed form is with a name that denotes an entity (or  several  overloaded
subprograms)  declared  immediately  within the package specification.  The
permission to omit the given check extends from the place of the pragma  to
the  end  of the declarative region associated with the innermost enclosing
\vblock statement\v507.  or  \vprogram  unit\v600..   For  a  pragma  given  in  a  package
specification,  the permission extends to the end of the scope of the named
entity.
If the pragma includes a name, the permission to omit the  given  check  is
further restricted:  it is given only for \voperations\v308. on the named object or
on all objects of the base type of a named type or subtype;  for calls of a
named subprogram;  for \vactivations\v903. of \vtasks\v900. of the named \vtask type\v901.;  or for
instantiations of the given generic unit.
The  following  checks  correspond  to  situations  in  which the \vexception\v1101.
\vCONSTRAINT_ERROR\v1101. may be raised; for these checks,  the  name  (if  present)
must denote either an object or a type.
ACCESS_CHECK          When  accessing  a  selected  component,  an  \vindexed\v402.
                      \vcomponent\v402.,  a  \vslice\v403.,  or  an \vattribute\v405., of an object
                      \vdesignated\v330. by an \vaccess value\v330., check that the  access
                      value is not null.
DISCRIMINANT_CHECK    Check that a \vdiscriminant\v326. of a  composite  value  has
                      the  value  imposed  by  a  \vdiscriminant  constraint\v327..
                      Also, when accessing a \vrecord component\v325.,  check  that
                      it exists for the current discriminant values.
INDEX_CHECK           Check that the bounds of an \varray\v321. value are equal  to
                      the  corresponding  bounds  of  an  \vindex constraint\v322..
                      Also, when accessing a \vcomponent of an array\v321.  object,
                      check  for  each \vdimension\v321. that the given index value
                      belongs to the range defined by  the  bounds  of  the
                      array  object.   Also,  when  accessing a slice of an
                      array object, check that the given \vdiscrete range\v321.  is
                      \vcompatible\v307.  with  the  range defined by the bounds of
                      the array object.
LENGTH_CHECK          Check that there is a  matching  component  for  each
                      component   of   an  array,  in  the  case  of  array
                      assignments, type conversions, and logical  operators
                      for arrays of boolean components.
RANGE_CHECK           Check that a  value  satisfies  a  \vrange  constraint\v310..
                      Also,  for  the  \velaboration\v301. of a subtype indication,
                      check that the \vconstraint\v305. (if present) is  compatible
                      with  the  \vtype  mark\v307..  Also, for an \vaggregate\v407., check
                      that an \vindex\v321. or discriminant value  belongs  to  the
                      corresponding   subtype.    Finally,  check  for  any
                      constraint   checks   performed    by    a    \vgeneric\v1206.
                      \vinstantiation\v1206..
The  following  checks  correspond  to  situations  in  which the \vexception\v1101.
\vNUMERIC_ERROR\v1101. is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names of \vnumeric types\v310..
DIVISION_CHECK        Check that the second operand is  not  zero  for  the
                      operations /, rem and mod.
OVERFLOW_CHECK        Check that the result of a \vnumeric operation\v315. does not
                      overflow.
The  following  check  corresponds  to  situations  in  which the \vexception\v1101.
\vPROGRAM_ERROR\v1101. is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names denoting task units, generic units, or subprograms.
ELABORATION_CHECK     When either a subprogram is called, a task activation
                      is   accomplished,  or  a  generic  instantiation  is
                      elaborated, check that the body of the  corresponding
                      unit has already been elaborated.
The  following  check  corresponds  to  situations  in  which the exception
STORAGE_ERROR is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names denoting \vaccess types\v330., task units, or subprograms.
STORAGE_CHECK         Check that execution of an \vallocator\v421. does not require
                      more space than is available for a \vcollection\v330..  Check
                      that the space available for a task or subprogram has
                      not been exceeded.
If  an  \verror situation\v1100. arises in the absence of the corresponding run-time
checks, the execution of the program is  \verroneous\v108.  (the  results  are  not
defined by the language).
\uExamples:\n
    \upragma \nSUPPRESS(RANGE_CHECK);
    \upragma \nSUPPRESS(INDEX_CHECK, ON => TABLE);
\uNotes:\n
For certain implementations, it may be impossible or too costly to suppress
certain  checks.  The corresponding SUPPRESS pragma can be ignored.  Hence,
the occurrence of such a pragma within a given unit does not guarantee that
the corresponding exception will not arise;  the  exceptions  may  also  be
propagated by called units.
:1200
12. \uGeneric Units\n
A generic unit is a \vprogram unit\v600. that is either a \vgeneric subprogram\v1201.  or  a
\vgeneric  package\v1201..   A generic unit is a template, which is parameterized or
not, and from which corresponding (nongeneric) \vsubprograms\v600. or \vpackages\v700.  can
be  obtained.   The resulting program units are said to be \vinstances\v1206. of the
original generic unit.
A generic unit  is  declared  by  a  \vgeneric  declaration\v1201..   This  form  of
\vdeclaration\v301.  has  a  \vgeneric  formal  part\v1201.  declaring  any  \vgeneric  formal\v1201.
\vparameters\v1201..  An instance of a generic unit is obtained as the result  of  a
\vgeneric  instantiation\v1206.  with  appropriate \vgeneric actual parameters\v1206. for the
generic formal parameters.  An  instance  of  a  generic  subprogram  is  a
subprogram.  An instance of a generic package is a package.
Generic  units are templates.  As templates they do not have the properties
that are specific to their nongeneric counterparts.  For example, a generic
subprogram can be instantiated but it cannot be called.  In  contrast,  the
instance  of  a generic subprogram is a nongeneric subprogram;  hence, this
instance can be called but it cannot be used to produce further  instances.
More details:
 12.1    \vGeneric Declarations\v1201.
 12.2    \vGeneric Bodies\v1205.
 12.3    \vGeneric Instantiation\v1206.
 12.4    \vExample of a Generic Package\v1213.
:1201
12.1  \uGeneric Declarations\n
A generic \vdeclaration\v301. declares a generic unit, which is  either  a  generic
subprogram  or a generic package.  A generic declaration includes a generic
formal part declaring any generic  formal  parameters.   A  generic  formal
parameter  can  be  an  \vobject\v302.;   alternatively  (unlike  a  \vparameter of a\v602.
\vsubprogram\v602.), it can be a \vtype\v305. or a \vsubprogram\v600..
    generic_declaration ::= generic_specification;
    generic_specification ::=
         generic_formal_part \vsubprogram_specification\v601.
       | generic_formal_part \vpackage_specification\v701.
    generic_formal_part ::= generic {generic_parameter_declaration}
    generic_parameter_declaration ::=
         \videntifier_list\v302. : [\uin \n[\uout\n]] type_mark [:= expression];
       | \utype \nidentifier \uis \ngeneric_type_definition;
       | \vprivate_type_declaration\v704.
       | \uwith \nsubprogram_specification [\uis \nname];
       | \uwith \nsubprogram_specification [\uis \n<>];
    generic_type_definition ::=
         (<>) | \urange \n<> | \udigits \n<> | \udelta \n<>
       | \varray_type_definition\v321. | \vaccess_type_definition\v330.
The terms generic formal object (or simply, formal object), generic  formal
type  (or  simply,  formal type), and generic formal subprogram (or simply,
formal subprogram) are  used  to  refer  to  corresponding  generic  formal
parameters.
The only form of \vsubtype indication\v307. allowed within a generic formal part is
a  \vtype  mark\v307. (that is, the subtype indication must not include an explicit
\vconstraint\v305.).  The \vdesignator\v601. of a generic subprogram must be an \videntifier\v203..
Outside the specification and body of a generic  unit,  the  \vname\v401.  of  this
program unit denotes the generic unit.  In contrast, within the declarative
region  associated with a generic subprogram, the name of this program unit
denotes the subprogram obtained by the current instantiation of the generic
unit.  Similarly, within the declarative region associated with  a  generic
package,  the name of this program unit denotes the package obtained by the
current instantiation.
The elaboration of a generic declaration has no other effect.
Examples of generic formal parts:
    generic     --  parameterless
    generic
       SIZE : NATURAL;  --  formal object
    generic
       LENGTH : INTEGER := 200;           -- formal object with a default
                                             expression
       AREA   : INTEGER := LENGTH*LENGTH; -- formal object with a default
                                             expression
    generic
       \utype \nITEM  \uis private\n;                       -- formal type
       \utype \nINDEX \uis\n (<>);                          -- formal type
       \utype \nROW   \uis array\n(INDEX \urange \n<>) \uof \nITEM; -- formal type
       \uwith\n \vfunction\v609. "<"(X, Y : ITEM) \ureturn\n BOOLEAN;    -- formal subprogram
Examples of generic declarations declaring generic subprograms:
    generic
       \utype\n ELEM \uis private\n;
    \vprocedure\v601. EXCHANGE(U, V : \uin out\n ELEM);
    generic
       \utype\n ITEM \uis private\n;
       \uwith function\n "*"(U, V : ITEM) \ureturn\n ITEM \uis\n <>;
    \ufunction\n SQUARING(X : ITEM) \ureturn\n ITEM;
Example of a generic declaration declaring a generic package:
    generic
       \utype\n ITEM   \uis private\n;
       \utype\n VECTOR \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM;
       \uwith function\n SUM(X, Y : ITEM) \ureturn\n ITEM;
    \upackage\n ON_VECTORS \ui\ns
       \ufunction\n SUM  (A, B : VECTOR) \ureturn\n VECTOR;
       \ufunction\n SIGMA(A    : VECTOR) \ureturn\n ITEM;
       LENGTH_ERROR : \uexception\n;
       \uend\n;
\uNotes:\n
Within a generic subprogram, the name of this program unit acts as the name
of a subprogram.  Hence this name can be \voverloaded\v610., and it can appear in a
recursive call of the current instantiation.  For  the  same  reason,  this
name  cannot  appear  after  the \vreserved word\v211. new in a (recursive) \vgeneric\v1206.
\vinstantiation\v1206..
An \vexpression\v410. that occurs in a generic formal part is  either  the  default
expression  for  a generic formal object of mode in, or a constituent of an
entry name given as default name for a formal subprogram,  or  the  default
expression for a parameter of a formal subprogram.  Default expressions for
generic  formal  objects  and default names for formal subprograms are only
evaluated for generic  instantiations  that  use  such  defaults.   Default
expressions  for  parameters  of  formal subprograms are only evaluated for
calls of the  formal  subprograms  that  use  such  defaults.   (The  usual
visibility  rules  apply  to  any  name  used in a default expression:  the
denoted \ventity\v301. must therefore be visible at the place of  the  expression.)
Neither   generic  formal  parameters  nor  their  \vattributes\v405.  are  allowed
constituents of \vstatic expressions\v422..
More details:
 12.1.1  \vGeneric Formal Objects\v1202.
 12.1.2  \vGeneric Formal Types\v1203.
 12.1.3  \vGeneric Formal Subprograms\v1204.
:1202
12.1.1  \uGeneric Formal Objects\n
The first form of \vgeneric parameter  declaration\v1201.  declares  \vgeneric  formal\v1201.
\vobjects\v1201..   The type of a generic formal object is the \vbase type\v305. of the type
denoted by the \vtype mark\v307. given in the  generic  parameter  declaration.   A
generic  parameter  declaration with several \videntifiers\v203. is equivalent to a
sequence of single generic parameter declarations, as explained in  section
A  generic  formal  object  has a \vmode\v601. that is either in or in out.  In the
absence of an explicit mode indication in a generic parameter  declaration,
the  mode  in  is  assumed;  otherwise the mode is the one indicated.  If a
generic parameter declaration ends with an expression,  the  expression  is
the  default  expression  of  the  \vgeneric  formal  parameter\v1201..   A  default
expression is only allowed  if  the  mode  is  in  (whether  this  mode  is
indicated explicitly or implicitly).  The type of a default expression must
be that of the corresponding generic formal parameter.
A  generic  formal object of mode in is a constant whose value is a copy of
the value supplied as the \vmatching generic actual parameter\v1206.  in  a  \vgeneric\v1206.
\vinstantiation\v1206.,  as described in section 12.3.  The type of a generic formal
object of mode in must not be a  \vlimited  type\v708.;   the  \vsubtype\v305.  of  such  a
generic  formal object is the subtype denoted by the type mark given in the
generic parameter declaration.
A generic formal object of mode in out is a \vvariable\v303. and denotes the \vobject\v302.
supplied  as  the  matching  \vgeneric  actual   parameter\v1206.   in   a   generic
instantiation, as described in section 12.3.  The \vconstraints\v305. that apply to
the  generic  formal  object  are those of the corresponding generic actual
parameter.
Note:
The constraints that apply to a generic formal object of mode  in  out  are
those  of  the corresponding generic actual parameter (not those implied by
the type mark that appears in the generic parameter declaration).  Whenever
possible (to avoid confusion) it is recommended that the  \vname\v401.  of  a  base
type be used for the \vdeclaration\v301. of such a formal object.  If, however, the
base  type is \vanonymous\v306., it is recommended that the subtype name defined by
the \vtype declaration\v305. for the base type be used.
:1203
12.1.2  \uGeneric Formal Types\n
A \vgeneric parameter declaration\v1201. that includes a \vgeneric type definition\v1201.  or
a  \vprivate  type  declaration\v704.  declares  a  \vgeneric formal type\v1201..  A generic
formal type denotes  the  subtype  supplied  as  the  corresponding  actual
parameter  in  a  generic instantiation, as described in 12.3(d).  However,
within a generic unit,  a  generic  formal  type  is  considered  as  being
distinct  from  all  other  (formal  or  nonformal)  types.   The  form  of
\vconstraint\v305. applicable to a formal type in a \vsubtype indication\v307.  depends  on
the \vclass of the type\v305. as for a nonformal type.
The only form of \vdiscrete range\v321. that is allowed within the \vdeclaration\v301. of a
generic formal (constrained) array type is a \vtype mark\v307..
The  \vdiscriminant  part\v326. of a generic formal private type must not include a
default expression for a discriminant.  (Consequently, a variable  that  is
declared  by  an  object  declaration  must be constrained if its type is a
generic formal type with discriminants.)
Within the declaration and \vbody of a generic unit\v1205., the \voperations\v305. available
for values of a generic formal type (apart from  any  additional  operation
specified  by  a  \vgeneric  formal subprogram\v1204.) are determined by the generic
parameter declaration for the formal type:
(a)  For a private type declaration, the  available  operations  are  those
     defined  in  section  7.4.2  (in particular, \vassignment\v502., \vequality\v413., and
     \vinequality\v413. are available for a private type unless it is limited).
(b)  For an \varray type  definition\v321.,  the  available  operations  are  those
     defined  in  section 3.6.2 (for example, they include the formation of
     \vindexed components\v402. and \vslices\v403.).
(c)  For an \vaccess type definition\v330.,  the  available  operations  are  those
     defined in section 3.8.2 (for example, \vallocators\v421. can be used).
The  four forms of generic type definition in which a box appears (that is,
the compound delimiter <>) correspond  to  the  following  major  forms  of
\vscalar type\v310.:
(d)  \vDiscrete types\v310.:  (<>)
     The  available operations are the operations common to \venumeration\v311. and
     \vinteger types\v314.; these are defined in section 3.5.5.
(e)  Integer types:  range <>
     The available operations are the operations of integer  types  defined
     in section 3.5.5.
(f)  \vFloating point types\v317.:  digits <>
     The available operations are those defined in section 3.5.8.
(g)  \vFixed point types\v319.:  delta <>
     The available operations are those defined in section 3.5.10.
In  all  of  the  above  cases  (a)  through (f), each operation implicitly
associated with a formal type (that is, other than an  operation  specified
by  a  formal  subprogram)  is  implicitly  declared  at  the  place of the
declaration of the formal type.  The same holds for a  formal  fixed  point
type,  except  for  the  \vmultiplying operators\v411. that deliver a result of the
type  \vuniversal_fixed\v319.  (see  4.5.5),  since  these  special  \voperators\v411.  are
declared in the \vpackage STANDARD\v806..
For  an  \vinstantiation\v1206. of the generic unit, each of these operations is the
corresponding basic operation or predefined operator of the matching actual
type.  For an operator, this rule applies even if  the  operator  has  been
redefined  for  the actual type or for some \vparent type\v309. of the actual type.
Examples of generic formal types:
    \utype\n ITEM \uis private\n;
    \utype\n BUFFER(LENGTH : NATURAL) \uis\n \vlimited private\v708.;
    \utype\n ENUM  \uis\n (<>);
    \utype\n INT   \uis range\n <>;
    \utype\n ANGLE \uis delta\n <>;
    \utype\n MASS  \uis digits\n <>;
    \utype\n TABLE \uis array\n (ENUM) \uof\n ITEM;
Example of a \vgeneric formal part\v1201. declaring a formal integer type:
    generic
       \utype\n RANK \uis range\n <>;
       FIRST  : RANK := RANK'FIRST;
       SECOND : RANK := FIRST + 1;  --  the operator "+" of the type RANK
:1204
12.1.3  \uGeneric Formal Subprograms\n
A  \vgeneric  parameter  declaration\v1201. that includes a \vsubprogram specification\v601.
declares a \vgeneric formal subprogram\v1201..
Two alternative forms of defaults can be specified in the declaration of  a
generic formal subprogram.  In these forms, the subprogram specification is
followed  by  the  \vreserved  word\v211.  is  and  either  a  box or the name of a
\vsubprogram\v600. or entry.  The matching rules for these defaults  are  explained
in section 12.3.6.
A generic formal subprogram denotes the subprogram, enumeration literal, or
entry  supplied  as the corresponding \vgeneric actual parameter\v1206. in a \vgeneric\v1206.
\vinstantiation\v1206., as described in section 12.3(f).
Examples of generic formal subprograms:
    \uwith function\n INCREASE(X : INTEGER) \ureturn\n INTEGER;
    \uwith function\n SUM(X, Y : ITEM) \ureturn\n ITEM;
    \uwith function\n "+"(X, Y : ITEM) \ureturn\n ITEM \uis\n <>;
    \uwith function\n IMAGE(X : ENUM) \ureturn\n STRING \uis\n ENUM'IMAGE;
    \uwith procedure\n UPDATE \uis\n DEFAULT_UPDATE;
\uNotes:\n
The \vconstraints\v305. that apply to a parameter of a formal subprogram are  those
of  the corresponding parameter in the specification of the matching actual
subprogram (not those  implied  by  the  corresponding  \vtype  mark\v307.  in  the
specification  of  the formal subprogram).  A similar remark applies to the
result of a function.   Whenever  possible  (to  avoid  confusion),  it  is
recommended  that the name of a \vbase type\v305. be used rather than the name of a
\vsubtype\v307. in any declaration of a formal subprogram.  If, however,  the  base
type  is  \vanonymous\v306., it is recommended that the subtype name defined by the
\vtype\v305. declaration be used.
The type specified for a formal parameter of a  generic  formal  subprogram
can  be  any  visible  type,  including  a  generic formal type of the same
generic formal part.
:1205
12.2  \uGeneric Bodies\n
The  \vbody\v333.  of a \vgeneric subprogram\v1201. or \vgeneric package\v1201. is a template for the
bodies of the corresponding \vsubprograms\v600. or  \vpackages\v700.  obtained  by  \vgeneric\v1206.
\vinstantiations\v1206..   The  syntax  of  a \vgeneric body\v1201. is identical to that of a
nongeneric body.
For each declaration of a generic subprogram, there must be a corresponding
body.
The \velaboration\v333. of a generic body has no other  effect  than  to  establish
that  the  body  can from then on be used as the template for obtaining the
corresponding \vinstances\v1206..
Example of a generic procedure body:
    procedure EXCHANGE(U, V : in out ELEM) is  --  see example in 12.1
       T : ELEM;  --  the generic formal type
    \ubegin\n
       T := U;
       U := V;
       V := T;
    \uend\n EXCHANGE;
Example of a generic function body:
    \ufunction\n SQUARING(X : ITEM) \ureturn\n ITEM \uis\n --  see example in 12.1
    \ubegin\n
       \ureturn\n X*X;  --  the formal operator "*"
    \uend\n;
Example of a generic package body:
    \vpackage body\v701. ON_VECTORS \uis\n --  see example in 12.1
       \ufunction\n SUM(A, B : VECTOR) \ureturn\n VECTOR \uis\n
          RESULT : VECTOR(A'RANGE);     --  the formal type VECTOR
          BIAS   : constant INTEGER := B'FIRST - A'FIRST;
       \ubegin\n
          \uif\n A'LENGTH /= B'LENGTH \uthen\n
            \uraise\n LENGTH_ERROR;
          \uend if\n;
          \ufor\n N \uin\n A'RANGE \uloop\n
             RESULT(N) := SUM(A(N), B(N + BIAS)); -- the formal
             \uend loop\n;                               function SUM
          \ureturn\n RESULT;
       \uend\n;
       \ufunction\n SIGMA(A : VECTOR) \ureturn\n ITEM \uis\n
          TOTAL : ITEM := A(A'FIRST);            -- the formal type ITEM
       \ubegin\n
          \ufor\n N \uin\n A'FIRST + 1 .. A'LAST \uloop\n
             TOTAL := SUM(TOTAL, A(N));          -- the formal function SUM
          \uend loop\n;
          \ureturn\n TOTAL;
       \uend\n;
    \uend\n;
:1206
12.3  \uGeneric Instantiation\n
An instance of a generic unit is declared by a generic instantiation.
    generic_instantiation ::=
         \upackage\n \videntifier\v203. \uis\n
             \unew\n generic_package_name [generic_actual_part];
       | \uprocedure\n identifier \uis\n
             \unew\n generic_procedure_name [generic_actual_part];
       | \ufunction\n designator \uis\n
             \unew\n generic_function_name [generic_actual_part];
    generic_actual_part ::=
       (generic_association {, generic_association})
    generic_association ::=
       [\vgeneric_formal_parameter\v1201. =>] generic_actual_parameter
    generic_formal_parameter ::= parameter_simple_name | \voperator_symbol\v601.
    generic_actual_parameter ::= \vexpression\v410. | variable_name
       | \vsubprogram_name\v601. | \ventry_name\v905. | \vtype_mark\v307.
An  explicit  generic  actual  parameter  must be supplied for each generic
formal parameter, unless the corresponding  \vgeneric  parameter  declaration\v1201.
specifies  that  a default can be used.  Generic associations can be either
positional or named  in  the  same  manner  as  parameter  associations  of
\vsubprogram  calls\v606..   If two or more formal subprograms have the
same  \vdesignator\v601.,  then  named  associations  are  not  allowed   for   the
corresponding generic parameters.
Each  generic  actual parameter must match the corresponding generic formal
parameter.  An expression can match a formal object of \vmode in\v1202.;  a variable
name can match a formal object of \vmode in out\v1202.;  a  subprogram  name  or  an
entry  name  can match a formal subprogram;  a type mark can match a formal
type.  The detailed  rules  defining  the  allowed  matches  are  given  in
sections 12.3.1 to 12.3.6;  these are the only allowed matches.
The  instance  is a copy of the generic unit, apart from the generic formal
part;  thus the instance of a generic package  is  a  \vpackage\v700.,  that  of  a
generic  procedure  is  a  procedure,  and  that of a generic function is a
function.  For each  occurrence, within the generic unit, of  a  \vname\v401.  that
denotes  a given \ventity\v301., the following list defines which entity is denoted
by the corresponding occurrence within the instance.
(a)  For a  name  that  denotes  the  generic  unit:     The  corresponding
     occurrence denotes the instance.
(b)  For a name that denotes a \vgeneric formal  object\v1201.  of  mode  in:    The
     corresponding  name  denotes  a  constant whose value is a copy of the
     value of the associated generic actual parameter.
(c)  For a name that denotes a generic formal object of mode in out:    The
     corresponding  name  denotes  the  \vvariable\v303.  named  by  the associated
     generic actual parameter.
(d)  For a name that denotes a \vgeneric  formal  type\v1201.:    The  corresponding
     name  denotes  the  subtype  named  by  the  associated generic actual
     parameter (the actual subtype).
(e)  For a name that denotes a \vdiscriminant\v326. of a generic formal type:   The
     corresponding name denotes the corresponding discriminant (there  must
     be one) of the actual type associated with the generic formal type.
(f)  For  a  name  that  denotes  a  \vgeneric  formal   subprogram\v1201.:      The
     corresponding  name  denotes  the  \vsubprogram\v600., enumeration literal, or
     entry named by the associated generic  actual  parameter  (the  actual
     subprogram).
(g)  For a name that  denotes  a  formal  parameter  of  a  generic  formal
     subprogram:    The corresponding name denotes the corresponding formal
     parameter  of  the  actual  subprogram  associated  with  the   formal
     subprogram.
(h)  For a name that denotes a local entity  declared  within  the  generic
     unit:    The  corresponding  name  denotes  the entity declared by the
     corresponding \vlocal declaration\v801. within the instance.
(i)  For a name that denotes  a  global  entity  declared  outside  of  the
     generic unit:   The corresponding name denotes the same global entity.
Similar  rules  apply  to  operators  and basic \voperations\v305.:  in particular,
formal operators follow a rule similar to rule (f), local operations follow
a rule similar to rule (h), and operations for global types follow  a  rule
similar  to rule (i).  In addition, if within the generic unit a predefined
operator or basic operation of a formal  type  is  used,  then  within  the
instance   the   corresponding   occurrence  refers  to  the  corresponding
predefined operation of the actual type associated with the formal type.
The above rules apply also to any type mark or (default)  expression  given
within the generic formal part of the generic unit.
For the \velaboration\v301. of a generic instantiation, each expression supplied as
an  explicit  generic  actual parameter is first evaluated, as well as each
expression that appears as a constituent of a variable name or  entry  name
supplied  as  an  explicit  generic  actual  parameter;   these \vevaluations\v411.
proceed in some order that is not defined by the language.  Then, for  each
omitted  generic association (if any), the corresponding default expression
or default name is evaluated;  such evaluations are performed in the  order
of  the  generic parameter declarations.  Finally, the implicitly generated
instance is elaborated.  The elaboration of  a  generic  instantiation  may
also  involve  certain constraint checks as described in later subsections.
Recursive generic instantiation is not allowed in the following sense:   if
a  given  generic  unit includes an instantiation of a second generic unit,
then the instance generated by  this  instantiation  must  not  include  an
instance  of  the  first  generic  unit (whether this instance is generated
directly, or indirectly by intermediate instantiations).
Examples of generic instantiations (see 12.1):
    \uprocedure\n SWAP \uis new\n EXCHANGE(ELEM => INTEGER);
    \uprocedure\n SWAP \uis new\n EXCHANGE(CHARACTER);  --  SWAP is \voverloaded\v610.
    \ufunction\n SQUARE \uis new\n SQUARING(INTEGER);
                                         --  "*" of INTEGER used by default
    \ufunction\n SQUARE \uis new\n SQUARING(ITEM => MATRIX, "*" => MATRIX_PRODUCT);
    \ufunction\n SQUARE \uis new\n SQUARING(MATRIX, MATRIX_PRODUCT);
                                                        -- same as previous
    \upackage\n INT_VECTORS \uis new\n ON_VECTORS(INTEGER, TABLE, "+");
Examples of uses of instantiated units:
    SWAP(A, B);
    A := SQUARE(A);
    T : TABLE(1 .. 5) := (10, 20, 30, 40, 50);
    N : INTEGER := INT_VECTORS.SIGMA(T);  --  150 (see 12.2 for the body of
                                              SIGMA)
    \uuse\n INT_VECTORS;
    M : INTEGER := SIGMA(T);  --  150
\uNotes:\n
Omission of a generic actual parameter is only allowed if  a  corresponding
default exists.  If default expressions or default names (other than \vsimple\v401.
\vnames\v401.) are used, they are evaluated in the order in which the corresponding
generic formal parameters are declared.
If  two  overloaded subprograms declared in a generic package specification
differ only by the (formal) type of  their  parameters  and  results,  then
there  exist  legal instantiations for which all calls of these subprograms
from outside the instance are ambiguous.  For example:
    generic
       \utype\n A \uis\n (<>);
       \utype\n B \uis private\n;
    \upackage\n G \uis\n
       \ufunction\n NEXT(X : A) \ureturn\n A;
       \ufunction\n NEXT(X : B) \ureturn\n B;
    \uend\n;
    \upackage\n P \uis new\n G(A => BOOLEAN, B => BOOLEAN);
    -- calls of P.NEXT are ambiguous
More details:
 12.3.1  \vMatching Rules for Formal Objects\v1207.
 12.3.2  \vMatching Rules for Formal Private Types\v1208.
 12.3.3  \vMatching Rules for Formal Scalar Types\v1209.
 12.3.4  \vMatching Rules for Formal Array Types\v1210.
 12.3.5  \vMatching Rules for Formal Access Types\v1211.
 12.3.6  \vMatching Rules for Formal Subprograms\v1212.
:1207
12.3.1  \uMatching Rules for Formal Objects\n
A \vgeneric formal parameter\v1201. of \vmode in\v1202. of a given  \vtype\v305.  is  matched  by  an
\vexpression\v410. of the same type.  If a \vgeneric unit\v1201. has a \vgeneric formal object\v1202.
of  mode  in,  a check is made that the value of the expression  belongs to
the subtype  denoted  by  the  \vtype  mark\v307.,  as  for  an  explicit  constant
declaration  (see  3.2.1). The \vexception CONSTRAINT_ERROR\v1101. is raised if this
check fails.
A generic formal parameter of \vmode in out\v1202. of a given type is matched by the
\vname\v401. of a \vvariable\v303. of the same type.  The variable must  not  be  a  \vformal\v601.
\vparameter\v601.  of  \vmode  out\v602. or a \vsubcomponent\v305. thereof.  The name must denote a
variable for which renaming is allowed (see 8.5).
\uNotes:\n
The type of a \vgeneric actual parameter\v1206. of mode in must  not  be  a  \vlimited\v708.
\vtype\v708..   The \vconstraints\v305. that apply to a generic formal parameter of mode in
out are those of the corresponding generic actual parameter  (see  12.1.1).
:1208
12.3.2  \uMatching Rules for Formal Private Types\n
A generic formal \vprivate type\v704. is matched by any \vtype\v305. or \vsubtype\v305. (the actual
subtype) that satisfies the following conditions:
  -  If the formal type is not limited, the  actual  type  must  not  be  a
     \vlimited  type\v708..  (If, on the other hand, the formal type is limited, no
     such condition is imposed on the corresponding actual type, which  can
     be limited or not limited.)
  -  If the formal type has a \vdiscriminant part\v326., the actual type must be  a
     type   with   the  same  number  of  \vdiscriminants\v326.;   the  type  of  a
     discriminant that appears at a given position in the discriminant part
     of the actual type must be the same as the type  of  the  discriminant
     that  appears  at  the  same  position in the discriminant part of the
     formal type;  and the actual subtype must be unconstrained.   (If,  on
     the  other hand, the formal type has no discriminants, the actual type
     is allowed to have discriminants.)
Furthermore, consider any occurrence of the \vname\v401. of the formal  type  at  a
place  where this name is used as an unconstrained \vsubtype indication\v307..  The
actual subtype must not be an \vunconstrained array type\v321. or an  unconstrained
\vtype  with  discriminants\v305.,  if any of these occurrences is at a place where
either a \vconstraint\v305. or \vdefault discriminants\v326. would be required for an \varray\v321.
\vtype\v321. or for a type with discriminants (see  3.6.1  and  3.7.2).   The  same
restriction  applies  to occurrences of the name of a subtype of the formal
type, and to occurrences of the  name  of  any  type  or  subtype  derived,
directly or indirectly, from the formal type.
If  a  generic  unit  has  a  formal  private  type with discriminants, the
\velaboration\v333. of  a  corresponding  \vgeneric  instantiation\v1206.  checks  that  the
subtype  of each discriminant of the actual type is the same as the subtype
of the corresponding  discriminant  of  the  formal  type.   The  \vexception\v1101.
\vCONSTRAINT_ERROR\v1101. is raised if this check fails.
:1209
12.3.3  \uMatching Rules for Formal Scalar Types\n
A  \vgeneric  formal  type\v1203. defined by (<>) is matched by any \vdiscrete\v310. subtype
(that is, any \venumeration\v311. or  \vinteger\v314.  subtype).   A  generic  formal  type
defined  by  range <> is matched by any integer subtype.   A generic formal
type defined by digits <> is matched by  any  \vfloating  point\v317.  subtype.   A
generic  formal  type  defined  by  delta  <> is matched by any \vfixed point\v319.
subtype.  No other matches are possible for these generic formal types.
:1210
12.3.4  \uMatching Rules for Formal Array Types\n
A  formal  \varray  type\v321. is matched by an actual array \vsubtype\v305. that satisfies
the following conditions:
  -  The formal array type and the actual array type  must  have  the  same
     dimensionality;  the \vformal type\v1201. and the actual subtype must be either
     both \vconstrained\v321. or both \vunconstrained\v321..
  -  For each \vindex\v321. position, the index type  must  be  the  same  for  the
     actual array type as for the formal array type.
  -  The component type must be the same for the actual array type  as  for
     the  formal  array type.  If the component type is other than a scalar
     type, then the component subtypes must be either both  constrained  or
     both unconstrained.
If  a  generic  unit  has  a  formal  array  type,  the  \velaboration\v333.  of  a
corresponding instantiation checks that the \vconstraints\v305.  (if  any)  on  the
component  type  are  the  same for the actual array type as for the formal
array type, and likewise that  for  any  given  index  position  the  index
subtypes  or  the  discrete  ranges  have  the  same bounds.  The \vexception\v1101.
\vCONSTRAINT_ERROR\v1101. is raised if this check fails.
Example:
    --  given the generic package
    generic
       \utype\n ITEM   i\us privat\ne;
       \utype\n INDEX  \uis\n (<>);
       \utype\n VECTOR \uis array\n (INDEX \urange\n <>) \uof\n ITEM;
       \utype\n TABLE  \uis array\n (INDEX) \uof\n ITEM;
    \upackage\n P \uis\n
       ...
    \uend\n;
    --  and the types
    \utype\n MIX    \uis array\n (COLOR \urange\n <>) \uof\n BOOLEAN;
    \utype\n OPTION \uis array\n (COLOR) \uof\n BOOLEAN;
    --  then MIX can match VECTOR and OPTION can match TABLE
    \upackage\n R \uis new\n P(ITEM   => BOOLEAN, INDEX => COLOR,
                       VECTOR => MIX,     TABLE => OPTION);
    --  Note that MIX cannot match TABLE and OPTION cannot match VECTOR
Note:
For the above rules, if any of the index or component types of  the  formal
array  type  is  itself  a  formal  type, then within the instance its name
denotes the corresponding actual subtype (see 12.3(d)).
:1211
12.3.5  \uMatching Rules for Formal Access Types\n
A  formal \vaccess type\v330. is matched by an actual access subtype if the type of
the designated \vobjects\v302. is the same for the actual type as  for  the  formal
type.   If  the  designated  type  is  other  than  a scalar type, then the
designated subtypes must be either both constrained or both  unconstrained.
If  a  generic  unit  has  a  formal  access  type,  the  \velaboration\v333.  of a
corresponding instantiation checks that any \vconstraints\v305. on  the  designated
objects are the same for the actual access subtype as for the formal access
type.  The \vexception CONSTRAINT_ERROR\v1101. is raised if this check fails.
Example:
    --  the formal types of the generic package
    generic
       \utype\n NODE \uis private\n;
       \utype\n LINK \uis access\n NODE;
    \upackage\n P \uis\n
       ...
    \uend\n;
    --  can be matched by the actual types
    \utype\n CAR;
    \utype\n CAR_NAME \uis access\n CAR;
    \utype\n CAR \uis\n
       \urecord\n
          PRED, SUCC : CAR_NAME;
          NUMBER     : LICENSE_NUMBER;
          OWNER      : PERSON;
       \uend record\n;
    --  in the following \vgeneric instantiation\v1206.
    \upackage\n R \uis new\n P(NODE => CAR, LINK => CAR_NAME);
Note:
For  the  above rules, if the designated type is itself a formal type, then
within the instance its name denotes the corresponding actual subtype  (see
12.3(d)).
:1212
12.3.6  \uMatching Rules for Formal Subprograms\n
A  formal  \vsubprogram\v600.  is  matched  by  an  actual  subprogram, enumeration
literal, or \ventry\v905. if both have the same \vparameter and result  type  profile\v603.
(see  6.6);   in  addition,  parameter  modes  must be identical for formal
parameters that are at the same parameter position.
If a generic unit has a default subprogram specified by a \vname\v401.,  this  name
must denote a subprogram, an enumeration literal, or an entry, that matches
the  formal subprogram (in the above sense).  The evaluation of the default
name takes place during the elaboration of each instantiation that uses the
default,  as defined in section 12.3.
If a generic unit has  a  default  subprogram  specified   by  a  box,  the
corresponding  actual parameter can be omitted if a subprogram, enumeration
literal, or entry  matching  the  formal  subprogram,  and  with  the  same
\vdesignator\v601.  as  the  formal subprogram, is directly visible at the place of
the \vgeneric instantiation\v1206.;  this subprogram, enumeration literal, or  entry
is  then used by default (there must be exactly one subprogram, enumeration
literal, or entry satisfying the previous conditions).
Example:
    --  given the generic function specification
    generic
       \utype\n ITEM \uis private\n;
       \uwith function\n "*" (U, V : ITEM) \ureturn\n ITEM \uis\n <>;
    \vfunction\v609. SQUARING(X : ITEM) \ureturn\n ITEM;
    --  and the function
    \ufunction\n MATRIX_PRODUCT(A, B : MATRIX) \ureturn\n MATRIX;
    --  the following instantiation is possible
    \ufunction\n SQUARE \uis new\n SQUARING(MATRIX, MATRIX_PRODUCT);
    --  the following instantiations are equivalent
    \ufunction\n SQUARE \uis new\n SQUARING(ITEM => INTEGER, "*" => "*");
    \ufunction\n SQUARE \uis new\n SQUARING(INTEGER, "*");
    \ufunction\n SQUARE \uis new\n SQUARING(INTEGER);
\uNotes:\n
The matching rules for  formal  subprograms  state  requirements  that  are
similar  to  those  applying to subprogram renaming declarations (see 8.5).
In particular, the name of a parameter of the formal subprogram need not be
the same as that of the corresponding parameter of the  actual  subprogram;
similarly,  for  these parameters, default expressions need not correspond.
A formal subprogram is matched by an \vattribute\v405. of a type if  the  attribute
is  a  function with a matching specification.  An enumeration literal of a
given type matches a parameterless formal function whose result type is the
given type.
:1213
12.4  \uExample of a Generic Package\n
The following example provides a possible formulation of stacks by means of
a  generic  package.   The  size  of  each  stack and the type of the stack
elements are provided as generic parameters.
    generic
       SIZE : POSITIVE;
       \utype\n ITEM \uis private\n;
    \upackage\n STACK \uis\n
       \uprocedure\n PUSH(E : \uin\n ITEM);
       \uprocedure\n POP (E : \uout\n ITEM);
       OVERFLOW, UNDERFLOW : \uexception\n;
    \uend\n STACK;
    \upackage body\n STACK \uis\n
       \utype\n TABLE \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM;
       SPACE : TABLE(1 .. SIZE);
       INDEX : NATURAL := 0;
       \uprocedure\n PUSH(E : \uin\n ITEM) \uis\n
       \ubegi\nn
          \uif\n INDEX >= SIZE \uthen\n
             \uraise\n OVERFLOW;
          \uend if\n;
          INDEX := INDEX + 1;
          SPACE(INDEX) := E;
       \uend\n PUSH;
       \uprocedure\n POP(E : \uout\n ITEM) \uis\n
       \ubegin\n
          \uif\n INDEX = 0 \uthen\n
             \uraise\n UNDERFLOW;
          \uend if\n;
          E := SPACE(INDEX);
          INDEX := INDEX - 1;
       \uend\n POP;
    \uend\n STACK;
Instances of this generic package can be obtained as follows:
    \upackage\n STACK_INT  \uis new\n STACK(SIZE => 200, ITEM => INTEGER);
    \upackage\n STACK_BOOL \uis new\n STACK(100, BOOLEAN);
Thereafter, the procedures of the instantiated packages can  be  called  as
follows:
    STACK_INT.PUSH(N);
    STACK_BOOL.PUSH(TRUE);
Alternatively,  a  generic  formulation  of  the type STACK can be given as
follows (package body omitted):
    generic
       \utype\n ITEM \uis private\n;
    \upackage\n ON_STACKS \uis\n
       \utype\n STACK(SIZE : POSITIVE) \uis limited private\n;
       \uprocedure\n PUSH(S : \uin out\n STACK; E : in  ITEM);
       \uprocedure\n POP (S : \uin out\n STACK; E : out ITEM);
       OVERFLOW, UNDERFLOW : \uexception\n;
    \uprivate\n
       \utype\n TABLE \uis array\n (POSITIVE \urange\n <>) \uof\n ITEM;
       \utype\n STACK(SIZE : POSITIVE) \uis\n
          \urecord\n
             SPACE : TABLE(1 .. SIZE);
             INDEX : NATURAL := 0;
          \uend record\n;
    \uend\n;
In order to use such a  package,  an  instantiation  must  be  created  and
thereafter stacks of the corresponding type can be declared:
    declare
       \upackage\n STACK_REAL \uis new\n ON_STACKS(REAL); \uuse\n STACK_REAL;
       S : STACK(100)
    \ubegin\n
       ...
       PUSH(S, 2.54);
       ...
    \uend\n;
:1300
13. \uRepresentation Clauses and Implementation-Dependent Features\n
This chapter describes representation clauses, certain implementation-
dependent features, and other features that are used in system
programming.
More details:
 13.1    \vRepresentation Clauses\v1301.
 13.2    \vLength Clause\v1302.
 13.3    \vEnumeration Representation Clauses\v1303.
 13.4    \vRecord Representation Clauses\v1304.
 13.5    \vAddress Clauses\v1305.
 13.6    \vChange of Representation\v1307.
 13.7    \vThe Package System\v1308.
 13.8    \vMachine Code Insertions\v1312.
 13.9    \vInterface to other Languages\v1313.
 13.10   \vUnchecked Programming\v1314.
:1301
13.1 \uRepresentation Clauses\n
Representation clauses specify how the \vtypes\v305. of the language are to be
mapped onto the underlying machine.  They can be provided to give more
efficient representation or to interface with features that are outside
the domain of the language (for example, peripheral hardware).
        representation_clause ::=
              type_representation_clause | address_clause
        type_representation_clause ::= \vlength_clause\v1302.
              | \venumeration_representation_clause\v1303.
              |\vrecord_representation_clause\v1304.
A type representation clause applies either to a type or to a first
\vnamed\v401. \vsubtype\v305. (that is, to a \vsubtype declared\v307. by a type \vdeclaration\v301.,
the base type being therefore anonymous).  Such a representation
clause applies to  all \vobjects\v302. that have this type or this first named
subtype.  At most one enumeration or record representation clause is
\vallowed\v108. for a given type: an enumeration representation clause is only
allowed for an enumeration type; a record representation clause, only
for a record type.  (On the other hand, more than one length clause
can be provided for a given type; moreover, both a length clause and
an enumeration or record representation clause can be provided.)  A
length clause is the only form of representation clause allowed for a
\vtype derived\v309. from a \vparent type\v309. that has (user-defined) \vderivable\v310.
\vsubprograms\310..
An \vaddress clause\v1305. applies either to an object; to a \vsubprogram\v600.,
\vpackage\v700., or \vtask unit\v900.; or to an \ventry\v905..  At most one address clause is
allowed for any of these entities.
A representation clause and declaration of the \ventity\v301. to which the
clause applies \vmust\v108. both \voccur immediately within\v801. the same \vdeclarative\v333.
\vpart\v333., \vpackage specification\v701., or \vtask specification\v901.; the declaration
must occur before the clause.  In the absence of a representation
clause for a given declaration, a default representation of this
declaration is determined by the implementation.  Such a default
determination occurs no later than the end of the immediately
enclosing declarative part, package specification, or task
specification.  For a declaration given in a declarative part, this
default determination occurs before any enclosed \vbody\v333..
In the case of a type, certain occurrences of its name imply that the
representation of the type must already have been determined.
Consequently these occurrences force the default determination of any
aspect of the representation not already determined by a prior type
representation clause.  This default determination is also forced by
similar occurrences of the name of a subtype of the type, or of the
name of any type or subtype that has \vsubcomponents\v305. of the type.  A
forcing occurence is any occurrence other than in a type or subtype
declaration, a subprogram specification, an entry declaration, a \vdeferred\v704.
\vconstant declaration\v704., a \vpragma\v1310., or a representation clause for the type
itself. In any case, an occurrence within an \vexpression\v410. is always forcing.
A representation clause for a given entity must not appear after an
occurrence of the name of the entity if this occurrence forces a
default determination of representation for the entity.
Similar restrictions exist for address clauses. For an object, any
occurrence of its name (after the object declaration) is a forcing
occurrence.  For a subprogram, package, task unit, or entry, any
occurrence of a \vrepresentation attribute\v1310. of such an entity is a
forcing occurrence.
The effect of the elaboration of a representation clause is to define
the corresponding aspects of the representation.
The interpretation of some of the expressions that appear in
representation clauses is implementation_dependent, for example,
expressions specifying addresses.  An implementation may limit its
acceptance of representation clauses to those that can be handled
simply by the underlying hardware.  If a representation clause is
accepted by an implementation, the compiler must guarantee that the
net effect of the program is not changed by the presence of the clause,
except for address clauses and for parts of the program that interrogate
representation attributes. If a program contains a representation clause
that is not accepted, the program is \villegal\v108..  For each implementation,
the allowed representation clauses, and the conventions used for
implementation-dependent expressions, must be documented in Appendix F of
the reference manual.
Whereas a representation clause is used to impose certain
characteristics of the mapping of an entity onto the underlying
machine, pragmas can be used to provide an implementation, with
criteria for its selection of such a mapping.  The pragma PACK
specifies that storage minimization should be the main criterion when
selecting the representation of a record or array type.  Its form is
as follows:
        pragma PACK (type_simple_name);
Packing means that gaps between the storage areas allocated to
consecutive \vcomponents\v305. should be minimized.  It need not, however,
affect the mapping of each component onto storage.  This mapping can
itself be influenced by a pragma (or controlled by a representation
clause) for the component or component type.  The position of a PACK
pragma, and the restrictions on the named type, are governed by the
same rules as for a representation clause; in particular, the pragma
must appear before any use of a representation attribute of the packed
entity.
The pragma PACK is the only language-defied representation pragma.
Additional representation pragmas may be provided by an
implementation; these must be documented in Appendix F. (in contrast
to representation clauses, a pragma that is not accepted by the
implementation is ignored).
Note:
No representation clause is allowed for a \vgeneric formal type\v1203..
:1302
13.2 \uLength Clauses\n
A length clause specifies an amount of storage associated with a type.
length_clause ::= for \vattribute\v405. use simple_expression;
The \vexpression\v410. \vmust\v108. be of some \vnumeric type\v310. and is evaluated during the
\velaboration\v333. of the length clause (unless it is a \vstatic expression\v422.).  The
prefix of the attribute must denote either a type or a \vfirst named subtype\v321..
The prefix is called T in what follows.  The only allowed attribute
designators in a length clause are SIZE, STORAGE_SIZE, and SMALL.  The
effect of the length clause depends on the attribute designator:
(a)  Size specification: T'SIZE
     The expression must be a static expression of some \vinteger type\v314..  The
     value of the expression specifies an upper bound for the number of
     bits to be allocated to \vobjects\v302. of the type or first named subtype T.
     The size specification must \vallow\v108. for enough storage space to
     accommodate every allowable value of these objects. A size
     specification for a \vcomposite type\v305. may affect the size of the gaps
     between the storage areas allocated to consecutive components. On the
     other hand, it need not affect the size of the storage area allocated
     to each component.
     The size specification is only allowed if the \vconstraints\v305. on T and on
     its \vsubcomponents\v305. (if any) are static.  In the case of an
     unconstrained \varray type\v321., the \vindex subtypes\v321. must also be static.
(b)  Specification of \vcollection\v330. size: T'STORAGE_SIZE
     The prefix T must denote an \vaccess type\v330.. The expression must be of
     some integer type (but need not be static); its value specifies the
     number of \vstorage units\v1308. to be reserved for the collection, that is,
     the storage space needed to contain all objects \vdesignated\v330. by values
     of the access type and by values of other types derived form the
     access type, directly or indirectly.  This form of length clause is
     not allowed for a type derived from an access type.
(c)  Specification of storage for a \vtask activation\v903.: T'STORAGE _SIZE
     The prefix T must denote a \vtask type\v902..  The expression must be of some
     integer type (but need not be static); its value specifies the number
     of storage units to be reserved for an activation (not the code) of a
     task of the type.
(d)  Specification of small for a \vfixed point type\v319.: T'SMALL
     The prefix T must denote the first named subtype of a fixed point
     type. The expression must be a static expression of some \vreal type\v316.;
     its value must be greater than the delta of the first named subtype.
     The effect of the length clause is to use this value of small for the
     representation of values of the fixed point base type.  (The length
     clause thereby also affects the amount of storage for objects that
     have this type).
\uNotes:\n
A size specification is allowed for an access, task, or fixed point type,
whether or not another form of length clause is also given for the type.
What is considered to be part of the storage reserved for a collection or
for an activation of a \vtask\v900. is implementation-dependent.  The control
afforded by length clauses is therefore relative to the implementation
conventions.  For example, the language does not define whether the storage
reserved for an activation of a task includes any storage needed for the
collection associated with an access type declared within the task body.
Neither does it define the method of allocation for objects denoted by
values of an access type.  For example, the space allocated could be on a
stack; alternatively, a general dynamic aliocation scheme or fixed storage
could be used.
The objects allocated in a collection need not have the same size if the
designated type is an unconstrained array type or an unconstrained type
with discriminants.  Note also that the \vallocator\v421. itself may require some
space for internal tables and links.  Hence a length clause for the
collection of an access type does not always give precise control over the
maximum number of allocated objects.
\uExamples:\n
      --assumed declarations:
      \utype\n MEDIUM \uis range\n 0 .. 65000;
      \utype\n SHORT  \uis delta\n 0.01 \urange\n -100.0 .. 100.0;
      \utype\n DEGREE \uis delta\n 0.1  \urange\n -360.0 .. 360.0;
      BYTE  : \uconstant\n := 8;
      PAGE  : \uconstant\n := 2000;
      --length clauses:
      \ufor\n COLOR'SIZE  \uuse\n 1*BYTE; -- see 3.5.1
      \ufor\n MEDIUM'SIZE \uuse\n 2*BYTE;
      \ufor\n SHORT'SIZE  \uuse\n 15;
      \ufor\n CAR_NAME'STORAGE_SIZE \uuse\n -- approximately 2000 cars
              2000*((CAR'SIZE/SYSTEM.STORAGE_UNIT) +1);
      \ufor\n KEYBOARD_DRIVERS'STORAGE_SIZE \uuse\n 1*PAGE;
\ufor\n DEGREE'SMALL \uuse\n 360.0/2**(SYSTEM.STORAGE_UNIT -1);
Notes on the \uExamples:\n
In the length clause for SHORT, fifteen bits is the minimum necessary,
since the type definition requires SHORT'SMALL=2**(-7) and SHORT'MANTISSA =
14.  The length clause for DEGREE forces the model numbers to exactly span
the range of the type.
:1303
13.3 \uEnumeration Representation Clauses\n
An enumeration \vrepresentation clause\v1301. specifies the internal codes for the
\vliterals\v406. of the \venumeration type\v311. that is named in the clause.
      enumeration_representation_clause ::= for type_simple_name use
               \vaggregate\v407.;
The aggregate used to specify this mapping is written as a one-dimensional
aggregate, for which the \vindex subtype\v321. is the enumeration \vtype\v305. and the
component \vtype is universal_integer\v314..
All literals of the enumeration type must be provided with distinct integer
codes, and all \vchoices\v328.. and \vcomponent\v305. values given in the aggregate must be
static.  The integer codes specified for the enumeration type must satisfy
the predefined \vordering relation\v311. of the type.
Example:
      \utype\n MIX_CODE \uis\n (ADD, SUB, MUL, LDA, STA, STZ);
      \ufor\n MIX_CODE \uuse\n
         (ADD => 1, SUB =.2, MUL => 3, LDA => 8, STA => 24, STZ =>33);
\uNotes:\n
The attributes SUCC, PRED, and POS are defined even for enumeration types
with a noncontiguous representation; their definition corresponds to the
(logical) \vtype declaration\v306. and is not affected by the enumeration
representation clause.  In the example, because of the need to avoid the
omitted values, these \vfunctions\v609. are likely to be less efficiently
implemented than they could be in the absence of a representation clause.
Similar considerations apply when such types are used for indexing.
:1304
13.4 \uRecord Representation Clauses\n
A record representation clause specifies the storage representation of
records, that is, the order, position, and size of \vrecord components\v325.
(including \vdiscriminants\v326., if any).
      record_representation_clause ::=
        \ufor\n type_simple_name \uuse\n
          \urecord\n [alignment_clause]
            {component clause}
          \uend record\n;
      alignment_clause ::= \uat mod\n static_simple_expression;
      component_clause ::=
        component_name at static_simple_expression \vrange\v310. static_range;
The \vsimple expression\v410. given after the reserved words at mod in an alignment
clause, or after the reserved word at in a component clause, \vmust\v108. be a
\vstatic expression\v422. of some \vinteger type\v314..  If the bounds of the range of a
component clause are defined by simple expressions, then each bound of the
range must be defined by a static expression of some integer type, but the
two bounds need not have the same integer type.
An alignment clause forces each record of the given type to be allocated at
a starting address that is a multiple of the value of the given expression
(that is, the address modulo the expression must be zero). An
implementation may place restrictions on the allowable alignments.
A component clause specifies the storage place of a component, relative to
the start of the record.  The integer defined by the static expression of a
component clause is a relative address expressed in \vstorage units\v1308..  The
range defines the bit positions of the storage place, relative to the
storage unit.  The first storage unit of a record is numbered zero.The
first bit of a storage unit is numbered zero.  The ordering of bits in a
storage unit is machine_dependent and may extend to adjacent storage units
(For a specific machine, the size in bits of a storage unit is given by the
configuration-dependent \vnamed number\v302. SYSTEM.STORAGE_UNIT.)  Whether a
component is allowed to overlap a storage boundary, and if so, how, is
implementation-defined.
At most one component clause is allowed for each component of the record
type, including for each discriminant (component clauses may be given for
some, all, or none of the components).  If no component clause is given for
a component, then the choice of the storage place for the component is left
to the compiler. If component clauses are given for all components, the
record representation clause completely specifies the representation of the
\vrecord type\v325. and must be obeyed exactly by the compiler.
Storage places within a record \vvariant\v328. must not overlap, but overlap of the
storage for distinct variants is allowed.  Each component clause must \vallow\v108.
for enough storage space to accommodate  every allowable value of the
component.  A component clause is only allowed for a component if any
\vconstraint\v305. on this component or on any of its \vsubcomponents\v305. is static.
An implementation may generate names that denote implementation-dependent
components (for example, one containing the offset of another component).
Such implementation-dependent names can be used in record representation
clauses (these names need not be \vsimple names\v401.; for example, they could be
implementation-dependent \vattributes\405.).
Example:
      WORD : \vconstant\v303. := 4;  --  storage unit is byte, 4 bytes per word
\utype\n STATE         \uis\n (A,M,W,P);
\utype\n MODE          \uis\n (FIX, DEC, EXP, SIGNIF);
\utype\n BYTE_MASK     \uis array\n (0.. 7) \uof\n BOOLEAN;
\utype\n STATE_MASK    \uis array\n (STATE) \uof\n BOOLEAN;
\utype\n MODE_MASK     \uis array\n (MODE)  \uof\n BOOLEAN;
\utype\n PROGRAM_STATUS_WORD \uis\n
  \urecord\n
      SYSTEM_MASK        : BYTE_MASK;
      PROTECTION_KEY     : INTEGER range 0 .. 3;
      MACHINE_STATE      : STATE_MASK;
      INTERRUPT_CAUSE    : INTERRUPTION_CODE;
      ILC                : INTEGER range 0 .. 3;
      CC                 : INTEGER range 0 .. 3;
      PROGRAM_MASK       : MODE_MASK;
      INST_ADDRESS       : ADDRESS;
\uend record\n;
  \ufor\n PROGRAM_STATUS_WORD \uuse\n
    \urecord at mod\n 8;
        SYSTEM_MASK      \uat\n 0*WORD \urange\n 0  .. 7;
        PROTECTION_KEY   \uat\n 0*WORD \urange\n 10 .. 11; -- bits 8,9 unused
        MACHINE_STATE    \uat\n 0*WORD \urange\n 12 .. 15;
        INTERRUPT_CAUSE  \uat\n 0*WORD \urange\n 16 .. 31;
        ILC              \uat\n 1*WORD \urange\n 0  .. 1;  -- second word
        CC               \uat\n 1*WORD \urange\n 2  .. 3;
        PROGRAM_MASK     \uat\n 1*WORD \urange\n 4  .. 7;
        INST_ADDRESS     \uat\n 1*WORD \urange\n 8  .. 31;
    \uend record\n;
  \ufor\n PROGRAM_STATUS_WORD'SIZE \uuse\n 8*SYSTEM.STORAGE_UNIT;
Note on the example:
The record representation clause defines the record layout.  The length
clause guarantees that exactly eight storage units are used.
:1305
13.5 \uAddress Clauses\n
An address clause specifies a required address in storage for an \ventity\v301..
      address_clause ::= for simple_name use at simple_expression;
The \vexpression\v410. given after the \vreserved word\v211. at must be of the \vtype\v305. ADDRESS
defined in the \vpackage\v700. SYSTEM (see 13.7); this package must be named by a
\vwith clause\v1002. that applies to the \vcompilation unit\v1001. in which the address
clause occurs.  The conventions that define the interpretation of a value
of the type ADDRESS as an address, as an interrupt level, or whatever it
may be, are implementation-dependent.  The allowed nature of the simple
\vname\v401. and the meaning of the corresponding address are as follows:
(a) Name of an \vobject\v302.: the address is that required for the object
    (\vvariable\v303. or \vconstant\v303.).
(b) Name of a \vsubprogram\v600., package, or \vtask unit\v900.: the address is that
    required for the machine code associated with the body of the program
    unit.
(c) Name of a single \ventry\v905.: the address specifies a hardware interrupt to
    which the single entry is to be linked.
If the simple name is that of a single task, the address clause is
understood to refer to the task unit and not to the \vtask object\v901..  In all
cases, the address clause is only legal if exactly one declaration with
this identifier occurs earlier, immediately within the same declarative
part, package specification, or task specification.  A name declared by a
renaming declaration is not allowed as the \vsimple name\v401..
Address clauses should not be used to achieve overlays of objects or
overlays of \vprogram units\v600.. Nor should a given interrupt be linked to more
than one entry. Any program using address clauses to achieve such effects
is \verroneous\v108..
Example:
    \ufor\n CONTROL \uuse at\n 16#0020#; -- assuming that SYSTEM.ADDRESS is an
                                    integer type
\uNotes:\n
The above rules imply that if two subprograms overload each other and are
visible at a given point, an address clause for any of them is not legal at
this point.  Similarly if a task specification declares entries that
overload each other, they cannot be interrupt entries.  The syntax does not
allow an address clause for a \vlibrary unit\v1001..  An implementation may provide
\vpragmas\v210. for the specification of program overlays.
More details:
 13.5.1  \vInterrupts\v1306.
:1306
13.5.1 \uInterrupts\n
An address clause given for an \ventry\v905. associates the entry with some device
that may cause an interrupt; such an entry is referred to in this section
as an interrupt entry.  If control information is supplied upon an
interrupt, it is passed to an associated interrupt entry as one or more
parameters of \vmode\v601. in; only parameters of this mode are \vallowed\v108..
An interrupt acts as an entry call issued by a hardware \vtask\v900. whose priority
is higher than the priority of the main program, and also higher than the
priority of any user-defined task (that is, any task whose type is declared
by a task unit in the program).  The entry call may be an ordinary entry
call, a \vtimed entry call\v910., or a \vconditional entry call\v909., depending on the
kind of interrupt and on the implementation.
If a \vselect statement\v907. contains both a \vterminate alternative\v908. and an \vaccept\v908.
\valternative\v908. for an interrupt entry, then an implementation may impose
further requirements for the selection of the terminate alternative in
addition to those given in section 9.4.
Example:
      \utask\n INTERRUPT_HANDLER \uis\n
        \uentry\n DONE;
        \ufor\n DONE \uuse at\n 16#40#; assuming that SYSTEM.ADDRESS is an integer
                                type
        \uend\n INTERRUPT_HANDLER;
\uNotes:\n
Interrupt entry calls need only have the semantics described above; they
may be implemented by having the hardware directly execute the appropriate
accept statements.
Queued interrupts correspond to ordinary entry calls. Interrupts that are
lost if not immediately processed correspond to conditional entry calls. It
is a consequence of the priority rules that an \vaccept statement\v905. executed in
response to an interrupt takes precedence over ordinary, user-defined
tasks, and can be executed without first invoking a scheduling action.
One of the possible effects of an address clause for an interrupt entry is
to specify the priority of the interrupt (directly or indirectly).  Direct
calls to an interrupt entry are allowed.
:1307
13.6  \uChange of Representation\n
At most one \vrepresentation clause\v1301. is allowed for a given \vtype\v305. and a given
aspect of its representation. Hence, if an alternative representation is
needed, it is necessary to declare a second type, \vderived\v309. from the first,
and to specify a different representation for the second type.
Example:
  -- PACKED_DESCRIPTOR and DESCRIPTOR are two different types
  -- with identical characteristics, apart from their representation
  \utype\n DESCRIPTOR \uis\n
      \urecord\n
        -- components of a descriptor
      \uend record\n;
  \utype\n PACKED_DESCRIPTOR \uis new\n DESCRIPTOR;
  \ufor\n PACKED_DESCRIPTOR \uuse\n
      \urecord\n
        -- component clauses for some or for all components
      \uend record\n;
Change of representation can now be accomplished by \vassignment\v502. with
explicit \vtype conversions\v419.:
      D : DESCRIPTOR;
      P : PACKED_DESCRIPTOR;
      P := PACKED_DESCRIPTOR (D); -- pack D
      D := DESCRIPTOR(P);         -- unpack P
:1308
13.7 \uThe Package System\n
For each implementation there is a predefined library \vpackage\v700. called SYSTEM
which includes the definitions of certain configuration-dependent
characteristics.  The specification of the package SYSTEM is
implementation-dependent and \vmust\v108. be given in Appendix F.  The visible part
of this package must contain at least the following declarations.
package SYSTEM is
      \vtype\v305. ADDRESS  \uis\n implementation_defined;
      \utype\n NAME     \uis\n implementation_defined_enumeration_type;
      SYSTEM_NAME    : \uconstant\n NAME  := implementation_defined;
      STORAGE_UNIT   : \uconstant\n := implementation_defined;
      MEMORY_SIZE    : \uconstant\n := implementation_defined;
      --System-Dependent \vNamed Numbers\v302.:
      MIN_INT        : \uconstant\n := implementation_defined;
      MAX_INT        : \uconstant\n := implementation_defined;
      MAX_DIGITS     : \uconstant\n := implementation_defined;
      MAX_MANTISSA   : \uconstant\n := implementation_defined;
      FINE_DELTA     : \uconstant\n := implementation_defined;
      TICK           : \uconstant\n := implementation_defined;
      --Other System_Dependent Declarations
      \usubtype\n PRIORITY \uis\n INTEGER \urange\n implementation_defined;
      ...
  \uend\n SYSTEM;
The type ADDRESS is the type of the addresses provided in \vaddress clauses\v1305.;
it is also the type of the result delivered by the \vattribute\v405. ADDRESS.
Values of the enumeration type NAME are the names of alternative machine
configurations handled by the implementation; one of these is the constant
SYSTEM_NAME.  The named number STORAGE_UNIT is the number of bits per
storage unit; the named number MEMORY_SIZE is the number of available
storage units in the configuration; these named numbers are of the type
universal_integer.
An alternative form of the package SYSTEM, with given values for any of
SYSTEM_NAME, STORAGE_UNIT, and MEMORY_SIZE, can be obtained by means of the
corresponding \vpragmas\v210..  These pragmas are only allowed at the start of a
compilation, before the first \vcompilation unit\v1001. (if any) of the compilation.
      \upragma\n SYSTEM_NAME (enumeration_literal);
The effect of the above pragma is to use the enumeration literal with the
specified identifier for the definition of the constant SYSTEM_NAME. This
pragma is only allowed if the specified identifier corresponds to one of
the literals of the type NAME.
      \upragma\n STORAGE_UNIT (\vnumeric_literal\v204.);
The effect of the above pragma is to use the value of the specified numeric
literal for the definition of the named number STORAGE_UNIT.
      \upragma\n MEMORY_SIZE (numeric_literal);
The effect of the above pragma is to use the value of the specified numeric
literal for the definition of the named number MEMORY_SIZE.
The compilation of any of these pragmas causes an implicit recompilation of
the package SYSTEM.  Consequently any compilation unit that names SYSTEM in
its context clause becomes obsolete after this implicit recompilation. An
implementation may impose further limitations on the use of these pragmas.
For example, an implementation may allow them only at the start of the
first compilation, when creating a new \vprogram library\v1001..
Note:
It is a consequence of the \vvisibility\v803. rules that a declaration given in the
package SYSTEM is not visible in a compilation unit unless this package is
mentioned by a \vwith clause\v1002. that applies (directly or indirectly) to the
compilation unit.
More details:
 13.7.1  \vSystem Dependent Named Numbers\v1309.
 13.7.2  \vRepresentation Attributes\v1310.
 13.7.3  \vRepresentation Attributes of Real Types\v1311.
:1309
13.7.1 \uSystem-dependent Named Numbers\n
Within the \vpackage SYSTEM\v1308., the following \vnamed numbers\v302. are declared.  The
numbers FINE_DELTA and TICK are of the \vtype\v305. \vuniversal_real\v316.; the others are
of the type \vuniversal_integer\v314..
MIN_INT      The smallest (most negative) value of all predefined integer
             types.
MAX_INT      The largest (most positive) value of all predefined \vinteger\v314.
             \vtypes\v314..
MAX_DIGITS   The largest value \vallowed\v108. for the number of significant
             decimal digits in a \vfloating point constraint\v317..
MAX_MANTISSA The largest possible number of binary digits in the mantissa
             of \vmodel numbers\v316. of a fixed point subtype.
FINE_DELTA   The smallest delta allowed in a \vfixed point constraint\v319. that
             has the \vrange constraint\v310. -1.0 .. 1.0.
TICK         The basic clock period, in seconds.
:1310
13.7.2 \uRepresentation Attributes\n
The values of certain implementation-dependent characteristics can be
obtatined by interrogating appropriate representation attributes.  These
attributes are described below.
For any \vobject\v302., \vprogram unit\v600., \vlabel\v501., or \ventry\v905. X:
X'ADDRESS      Yields the address of the first of the \vstorage units\v1308.
               allocated to X.  For a \vsubprogram\v600., \vpackage\v700., \vtask unit\v900. or
               label, this value refers to the machine code associated with
               the corresponding body or \vstatement\v500..  For an entry for which
               an \vaddress clause\v1305. has been given, the value refers to the
               corresponding hardware interrupt. The value of this
               attribute is of the \vtype\v305. ADDRESS defined in the package
               SYSTEM.
For any type or \vsubtype\v305. X or for any object X:
X'SIZE         Applied to an object, yields the number of bits allocated to
               hold the object.  Applied to a type or subtype, yields the
               minimum number of bits that is needed by the implementation
               to hold any possible object of this type or subtype. The
               value of this attribute is of the type \vuniversal_integer\v314..
For the above two representation attributes, if the prefix is the name of a
function, the attribute is understood to be an attribute of the function
(not of the result of calling the function).  Similarly, if the type of the
prefix is an \vaccess type\v330., the attribute is understood to be an attribute of
the prefix (not of the designated object: attributes of the latter can be
written with a prefix ending with the reserved word \uall\n).
For any \vcomponent\v305. C of a \vrecord object\v325. R:
R.C'POSITION   Yields the offset, from the start of the first storage unit
               occupied by the record, of the first of the storage units
               occupied by C.  This offset is measured in storage units.
               The value of this attribute is of the type
               universal_integer.
R.C'FIRST_BIT  Yields the offset, from the start of the first of the
               storage units occupied by C, of the last bit occupied by C.
               This offset is measured in bits.  The value of this
               attribute is of the type universal_integer.
R.C'LAST_BIT   Yields the offset, from the start of the first of the
               storage units occupied by C, of the last bit occupied by C.
               This offset is measured in bits. The value of this attribute
               is of the type universal_integer.
For any \vaccess type or subtype\v330. T:
T'STORAGE_SIZE Yields the total number of storage units reserved for the
               \vcollection\v330. associated with the \vbase type\v305. of T.  The value of
               this attribute is of the type universal_integer.
For any \vtask type\v902. or \vtask object\v902. T:
T'STORAGE_SIZE Yields the number of storage units reserved for each
               \vactivation\v903. of a task of the type T or for the activation of
               the task object T.  The value of this attribute is of the
               type universal_integer.
\uNotes:\n
For a task object X, the attribute X'SIZE gives the number of bits used to
hold the object X, whereas X'STORAGE_SIZE gives the number of storage units
allocated for the activation of the task designated by X.  For a \vformal\v601.
\vparameter\v601. X, if \vparameter passing\v602. is achieved by copy, then the attribute
X'ADDRESS yields the address of the local copy; if parameter passing is by
reference, then the address is that of the \vactual parameter\v602..
:1311
13.7.3 \uRepresentation Attributes of Real Types\n
For every \vreal type\v316. or \vsubtype\v305. T, the following machine-dependent
\vattributes\v405. are defined, which are not related to the \vmodel numbers\v316..
Programs using these attributes may thereby exploit properties that go
beyond the minimal properties associated with the \vnumeric type\v310. (see section
4.5.7 for the rules defining the accuracy of operations with real
operands). Precautions must therefore be taken when using these machine-
dependent attributes if portability is to be ensured.
For both \vfloating point\v317. and \vfixed point types\v319.:
T'MACHINE_ROUNDS    Yields the value TRUE if every predefined arithmetic
                    operation on values of the \vbase type\v305. of T either
                    returns an exact result or performs rounding; yields
                    the value FALSE otherwise.  The value of this attribute
                    is of the predefined type \vBOOLEAN\v313..
T'MACHINE_OVERFLOWS Yields the value TRUE if every \vpredefined operation\v308. on
                    values of the base type of T either provides a correct
                    result, or raises the exception \vNUMERIC_ERROR\v1101. in
                    overflow situations (see 4.5.7); yields the value FALSE
                    otherwise. The value of this attribute is of the
                    predefined type BOOLEAN.
For floating point types, the following attributes provide characteristics
of the underlying machine representation, in terms of the canonical form
defined in section 3.5.7:
T'MACHINE_RADIX     Yields the value of the \vradix\v317. used by the machine
                    representation of the base type of T (the digits are
                    extended digits in the range 0 to T'MACHINE_RADIX -1).
                    The value of this attribute is of the type
                    universal_integer.
T'MACHINE_EMAX      Yields the largest value of exponent for the machine
                    representation of the base type of T.  The value of
                    this attribute is of the type universal_integer.
T'MACHINE_EMIN      Yields the smallest (most negative) value of exponent
                    for the machine representation of the base type of T.
                    The value of this attribute is of the type
                    universal_integer.
Note: For many machines the largest machine representable number of type F
is almost
      (F'MACHINE_RADIX)**(F'MACHINE_EMAX),
and the smallest positive representable number is
      F'MACHINE_RADIX ** (F'MACHINE_EMIN -1)
:1312
13.8 \uMachine Code Insertions\n
A machine code insertion can be achieved by a call to a \vprocedure\v600. whose
\vsequence of statements\v501. contains code \vstatements\v500..
      code_statement ::= type_mark'record_aggregate;
A code statement is only \vallowed\v108. in the sequence of statements of a
\vprocedure body\v603..  If a procedure body contains code statements, then within
this procedure body the only allowed form of statement is a code statement
(\vlabeled\v501. or not), the only allowed \vdeclarative items\v333. are \vuse clauses\v505., and
no \vexception handler\v1102. is allowed (\vcomments\v209. and \vpragmas\v210. are allowed as
usual).
Each machine instruction appears as a record aggregate of a \vrecord type\v325.
that defines the corresponding instruction.  The base type of the type mark
of a code statement must be declared within the predefined library \vpackage\v700.
called MACHINE_CODE; this package must be named by a \vwith clause\v1002. that
applies to the \vcompilation unit\v1001. in which the code statement occurs.  An
implementation is not required to provide such a package.
An implementation is allowed to impose further restrictions on the \vrecord\v408.
\vaggregates\v408. allowed in code statements.  For example, it may require that
expressions contained in such aggregates be \vstatic expressions\v422..
An implementation may provide machine-dependent pragmas specifying register
conventions and calling conventions.  Such pragmas must be documented in
Appendix F
Example:
      M : MASK
      \uprocedure\n SET_MASK; \upragma\n INLINE(SET_MASK);
      \uprocedure\n SET_MASK \uis\n
        \uuse\n MACHINE_CODE;
      \ubegin\n
        SI_FORMAT'(CODE => SSM, B => M'BASE_REG, D => M'DISP);
        --  M'BASE_REG and M'DISP are implementation-specific predefined
            attributes
      \uend\n;
:1313
13.9 \uInterface to Other Languages\n
A subprogram written in another language can be called from an Ada program
provided that all communication is achieved via parameters and function
results. A \vpragma\v210. of the form
      \upragma\n INTERFACE (language_name, subprogram_name);
\vmust\v108. be given for each such \vsubprogram\v600.; a subprogram \vname\v401. is \vallowed\v108. to
stand for several \voverloaded subprograms\v610..  This pragma is allowed at the
place of a \vdeclarative item\v333., and must apply in this case to a subprogram
declared by an earlier declarative item of the same \vdeclarative part\v333. or
\vpackage specification\v701..  The pragma is also allowed for a \vlibrary unit\v1001.; in
this case the pragma must appear after the subprogram \vdeclaration\v301., and
before any subsequent \vcompilation unit\v1001..  The pragma specifies the other
language (and therby the calling conventions ) and informs the compiler
that an object module will be supplied for the corresponding subprogram.  A
body is not allowed for such a subprogram (not even in the form of a body
stub) since the instructions of the subprogram are written in another
language.
This capability need not be provided by all implementations.  An
implementation may place restrictions on the allowable forms and places of
parameters and calls.
Example:
      \upackage\n FORT_LIB \uis\n
        \ufunction\n SQRT (X : FLOAT) \ureturn\n FLOAT;
        \ufunction\n EXP  (X : FLOAT) \ureturn\n FLOAT;
      \uprivate\n
        \upragma\n INTERFACE(FORTRAN, SQRT);
        \upragma\n INTERFACE(FORTRAN, EXP);
      \uend\n FORT_LIB;
\uNotes:\n
The conventions used by other language processors that call Ada programs
are not part of the Ada language definition.  Such conventions must be
defined by these other language processors.
The pragma INTERFACE is not defined for generic subprograms.
:1314
13.10 \uUnchecked Programming\n
The predefined generic library subprograms UNCHECKED_DEALLOCATION and
UNCHECKED_CONVERSION are used for unchecked storage deallocation and for
unchecked \vtype\v305. conversions.
      generic
         \utype\n OBJECT \uis limited private\n;
         \utype\n NAME   \uis access\n  OBJECT;
      \uprocedure\n UNCHECKED_DEALLOCATION(X: \uin out\n NAME);
      generic
         \utype\n SOURCE \uis limited private\n;
         \utype\n TARGET \uis limited private\n;
      \ufunction\n UNCHECKED_CONVERSION(S : SOURCE) \ureturn\n TARGET;
More details:
 13.10.1 \vUnchecked Storage Deallocation\v1315.
 13.10.2 \vUnchecked Type Conversions\v1316.
:1315
13.10.1 \uUnchecked Storage Deallocation\n
Unchecked storage deallocation of an object \vdesignated\v330. by a value of an
\vaccess type\v330. is achieved by a call of a \vprocedure\v600. that is obtained by
instantiation of the \vgeneric procedure\v1201. UNCHECKED_DEALLOCATION.  For
example:
      \uprocedure\n FREE \uis new\n UNCHECKED_DEALLOCATION(object_type_name,
             access_type_name);
Such a FREE procedure has the following effect:
(a)  after executing FREE(X), the value of X is null;
(b) FREE(X), when X is already equal to null, has no effect;
(c) FREE(X), when X is not equal to null, is an indication that the \vobject\v302.
    designated by X is no longer required, and that the storage it occupies
    is to be reclaimed.
If X and Y designate the same object, then accessing this object through Y
is \verroneous\v108. if this access is performed (or attempted) after the call
FREE(X); the efeect of each such access is not defined by the language.
\uNotes:\n
It is a consequence of the \vvisibility\v803. rules that the generic procedure
UNCHECKED_DEALLOCATION is not visible in a \vcompilation unit\v1001. unless this
generic procedure is mentioned by a \vwith clause\v1002. that applies to the
compilation unit.
If X designates a \vtask object\902., the call FREE(X); has no effect on the \vtask\v900.
designated by the value of this task object.  The same holds for any
\vsubcomponent\v305. of the object designated by X, if this subcomponent is a task
object.
:1316
13.10.2 \uUnchecked Type Conversions\n
An unchecked type conversion can be achieved by a call of a function that
is obtained by \vinstantiation\v1206. of the \vgeneric function\v1201. UNCHECKED_CONVERSION.
The effect of an unchecked conversion is to return the (uninterpreted)
parameter value as a value of the target \vtype\v305., that is, the bit pattern
defining the source value is returned unchanged as the bit pattern defining
a value of the target type.  An implementation may place restrictions on
unchecked conversions, for example, restrictions dependeing on the
respective sizes of objects of the source and target type. Such
restrictions must be documented in appendix F.
Whenever unchecked conversions are used, it is the programmer's
responsibility to ensure that these conversions maintain the properties
that are guaranteed by the language for objects of the target type.
Programs that violate these properties by means of unchecked conversions
are \verroneous\v108..
Note:
It is a consequence of the visibility rules that the generic function
UNCHECKED_CONVERSION is not visible in a \vcompilation unit\v1001. unless this
generic function is mentioned by a \vwith clause\v1001. that applies to the
compilation unit.
:1400
14. \uInput-Output\n
Input-output  is  provided in the language by means of predefined packages.
The  generic  packages  \vSEQUENTIAL_IO\v1402.  and  \vDIRECT_IO\v1402.  define  input-output
operations  applicable  to  files  containing  elements  of  a  given type.
Additional operations for text input-output are  supplied  in  the  \vpackage\v1408.
\vTEXT_IO\v1408..   The  \vpackage  IO_EXCEPTIONS\v1420. defines the exceptions needed by the
above three packages.  Finally, a  \vpackage  LOW_LEVEL_IO\v1421.  is  provided  for
direct control of peripheral devices.
More details:
 14.1    \vExternal Files and File Objects\v1401.
 14.2    \vSequential and Direct Files\v1402.
 14.3    \vText Input-Output\v1408.
 14.4    \vExceptions in Input-Output\v1419.
 14.5    \vSpecification of the Package IO_EXCEPTIONS\v1420.
 14.6    \vLow Level Input-Output\v1421.
 14.7    \vExample of Input-Output\v1422.
:1401
14.1  \uExternal Files and File Objects\n
Values input from the external environment of the program, or output to the
environment, are considered to occupy external files.  An external file can
be  anything external to the program that can produce a value to be read or
receive a value to be written.  An external file is identified by a  \vstring\v324.
(the  name).   A  second  string  (the form) gives further system-dependent
characteristics that may be associated with the file, such as the  physical
organization   or   access   rights.    The   conventions   governing   the
interpretation of such strings must be documented in Appendix F.
Input and output operations are expressed as operations on objects of  some
file  type,  rather  than  directly in terms of the external files.  In the
remainder of this chapter, the term file is always used to refer to a  file
object;   the term external file is used otherwise.  The values transferred
for a given file must all be of one type.
Input-output for \vsequential files\v1402. of values of a  single  element  type  is
defined  by  means  of  the generic package SEQUENTIAL_IO.  The skeleton of
this package is given below.
    \uwith\n IO_EXCEPTIONS;
    \ugeneric\n
       \utype\n ELEMENT_TYPE \uis private\n;
    \vpackage SEQUENTIAL_IO\v1402. \uis\n
       \utype\n FILE_TYPE \uis limited private\n;
       \utype\n \vFILE_MODE\v1405. \uis\n (IN_FILE, OUT_FILE);
       ...
       \vprocedure OPEN\v1403. (FILE : \uin out\n FILE_TYPE; ...);
       ...
       \vprocedure READ\v1406. (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE);
       \vprocedure WRITE\v1406.(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE);
       ...
    \uend\n SEQUENTIAL_IO;
In order to define \vsequential input-output\v1404. for a  given  element  type,  an
instantiation  of  this  generic  unit,  with  the  given  type  as  actual
parameter,  must  be  declared.   The  resulting   package   contains   the
declaration  of  a file type (called FILE_TYPE) for files of such elements,
as well as the operations applicable to these  files,  such  as  the  OPEN,
READ, and WRITE procedures.
Input-output  for  \vdirect  access\v1402.  files  is  likewise defined by a generic
package called \vDIRECT_IO\v1402..  Input-output in human-readable form  is  defined
by the (nongeneric) \vpackage TEXT_IO\v1408..
Before \vinput\v1404. or \voutput\v1404. operations can be performed on a file, the file must
first be associated with an external file.  While such an association is in
effect,  the  file is said to be open, and otherwise the file is said to be
closed.
The language does not define what  happens  to  external  files  after  the
completion  of the main program (in particular, if corresponding files have
not  been  closed).   The  effect  of  input-output  for  access  types  is
implementation-dependent.
An open file has a current mode, which is a value of one of the \venumeration\v311.
\vtypes\v311.
 \utype\n FILE_MODE \uis\n (IN_FILE, INOUT_FILE, OUT_FILE);  --  for DIRECT_IO
 \utype\n FILE_MODE \uis\n (IN_FILE, OUT_FILE);   --  for SEQUENTIAL_IO and TEXT_IO
These  values correspond respectively to the cases where only reading, both
reading and writing, or only writing are to be performed.  The  mode  of  a
file can be changed.
Several  file  management  operations  are common to the three input-output
packages.  These operations are described in section 14.2.1 for  sequential
and  \vdirect files\v1402..  Any additional effects concerning text input-output are
described in section 14.3.1.
The \vexceptions\v1100. that can be raised by a call of an  input-output  subprogram
are  all  defined  in  the  \vpackage IO_EXCEPTIONS\v1420.;  the situations in which
they can be raised are described, either following the description  of  the
subprogram  (and  in  section  14.4), or in Appendix F in the case of error
situations that are implementation-dependent.
\uNotes:\n
Each instantiation of the  generic  packages  SEQUENTIAL_IO  and  DIRECT_IO
declares  a  different  type  FILE_TYPE;   in the case of TEXT_IO, the type
FILE_TYPE is unique.
A bidirectional device  can  often  be  modeled  as  two  sequential  files
associated  with the device, one of mode IN_FILE, and one of mode OUT_FILE.
An implementation may restrict the number of files that may  be  associated
with a given external file.  The effect of sharing an external file in this
way by several file objects is implementation-dependent.
:1402
14.2  \uSequential and Direct Files\n
Two  kinds  of access to external files are defined:  sequential access and
direct access.  The corresponding file types and the associated  operations
are  provided  by the generic packages SEQUENTIAL_IO and DIRECT_IO.  A file
object to be used for sequential access is called a  sequential  file,  and
one to be used for direct access is called a direct file.
For  sequential access, the file is viewed as a sequence of values that are
transferred in the order of their appearance (as produced by the program or
by the environment).  When the file is opened,  transfer  starts  from  the
beginning of the file.
For  direct  access,  the  file  is  viewed  as a set of elements occupying
consecutive positions in linear order;  a value can be  transferred  to  or
from  an  element of the file at any selected position.  The position of an
element is specified by its index, which is a number, greater than zero, of
the implementation-defined integer type \vCOUNT\v1408..  The first element, if  any,
has  index  one;   the  index  of  the  last element, if any, is called the
current size;  the current size is zero if  there  are  no  elements.   The
current size is a property of the external file.
An  open  direct  file has a current index, which is the index that will be
used by the next read or write operation.  When a direct  file  is  opened,
the  current  index is set to one.  The current index of a direct file is a
property of a file object, not of an external file.
All three \vfile modes\v1401. are allowed for direct files.  The only allowed  modes
for sequential files are the modes \vIN_FILE\v1401. and \vOUT_FILE\v1401..
More details:
 14.2.1  \vFile Management\v1403.
 14.2.2  \vSequential Input-Output\v1404.
 14.2.3  \vSpecification of the Package Sequential_IO\v1405.
 14.2.4  \vDirect Input-Output\v1406.
 14.2.5  \vSpecification of the Package Direct_IO\v1407.
:1403
14.2.1  \uFile Management\n
The  procedures  and  functions  described  in this section provide for the
control of \vexternal files\v1401.;  their declarations are repeated in each of  the
three  packages  for  sequential,  direct, and text input-output.  For text
input-output, the  procedures  CREATE,  OPEN,  and  RESET  have  additional
effects described in section 14.3.1.
    \uprocedure\n CREATE(FILE : \uin out\n \vFILE_TYPE\v1401.;
                     \vMODE\v1401. : \uin\n \vFILE_MODE\v1401. := default_mode;
                     \vNAME\v1401. : \uin\n STRING := "";
                     FORM : \uin\n STRING := "");
          Establishes  a  new  external file, with the given name and form,
          and associates this external file with the given \vfile\v1401..  The given
          file is left open.  The \vcurrent mode\v1401. of the given file is set  to
          the  given  access  mode.   The  default  access mode is the mode
          \vOUT_FILE\v1401. for sequential and text input-output;  it  is  the  mode
          \vINOUT_FILE\v1406.  for direct input-output.  For \vdirect access\v1402., the size
          of the created file is implementation-dependent.  A  null  string
          for  NAME specifies an external file that is not accessible after
          the completion of the main program (a temporary  file).   A  null
          string  for  FORM specifies the use of the default options of the
          implementation for the external file.
          The \vexception STATUS_ERROR\v1419. is raised if the given file is already
          \vopen\v1401..  The \vexception NAME_ERROR\v1419. is raised if the string given  as
          NAME  does not allow the identification of an external file.  The
          \vexception USE_ERROR\v1419. is raised if, for  the  specified  mode,  the
          environment  does  not  support creation of an external file with
          the given name (in the absence of NAME_ERROR) and form.
    \uprocedure\n OPEN(FILE : \uin out\n FILE_TYPE;
                   MODE : \uin\n FILE_MODE;
                   NAME : \uin\n STRING;
                   FORM : \uin\n STRING := "");
          Associates the given file with an existing external  file  having
          the  given  name and form, and sets the current mode of the given
          file to the given mode.  The given file is left open.
          The exception STATUS_ERROR is raised if the given file is already
          open.  The exception NAME_ERROR is raised if the string given  as
          NAME  does  not allow the identification of an external file;  in
          particular, this exception is raised if no external file with the
          given name exists.  The exception USE_ERROR is raised if, for the
          specified mode, the environment does not support opening  for  an
          external  file with the given name (in the absence of NAME_ERROR)
          and form.
    \uprocedure\n CLOSE(FILE : \uin out\n FILE_TYPE);
          Severs the association between the given file and its  associated
          external file.  The given file is left closed.
          The  exception  STATUS_ERROR  is  raised if the given file is not
          open.
    \uprocedure\n DELETE(FILE : \uin out\n FILE_TYPE);
          Deletes the external file associated with the  given  file.   The
          given \vfile is closed\v1401., and the external file ceases to exist.
          The  exception  STATUS_ERROR  is  raised if the given file is not
          open.  The exception USE_ERROR is raised if (as fully defined  in
          Appendix F) deletion of the external file is not supported by the
          environment.
    \uprocedure\n RESET(FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE);
    \uprocedure\n RESET(FILE : \uin out\n FILE_TYPE);
          Resets  the  given  file  so  that reading from or writing to its
          elements can be restarted from the beginning  of  the  file;   in
          particular,  for  direct access this means that the current index
          is set to one.  If a MODE parameter is supplied, the current mode
          of the given file is set to the given mode.
          The exception STATUS_ERROR is raised if the  file  is  not  open.
          The  exception  USE_ERROR  is  raised if the environment does not
          support resetting  for  the  external  file  and,  also,  if  the
          environment  does not support resetting to the specified mode for
          the external file.
    \ufunction\n MODE(FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE;
          Returns the current mode of the given file.
          The exception STATUS_ERROR is raised if the file is not open.
    \ufunction\n NAME(FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
          Returns a string which  uniquely  identifies  the  external  file
          currently associated with the given file (and may thus be used in
          an   OPEN  operation).   If  an  environment  allows  alternative
          specifications of the  name  (for  example,  abbreviations),  the
          string  returned  by  the  function  should  correspond to a full
          specification of the name.
          The exception STATUS_ERROR is raised if the  given  file  is  not
          open.
    \ufunction\n FORM(FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
          Returns   the   \vform  string\v1401.  for  the  external  file  currently
          associated  with  the  given  file.   If  an  environment  allows
          alternative    specifications   of   the   form   (for   example,
          abbreviations using default options), the string returned by  the
          function  should  correspond to a full specification (that is, it
          should  indicate  explicitly  all  options  selected,   including
          default options).
          The  exception  STATUS_ERROR  is  raised if the given file is not
          open.
    \ufunction\n IS_OPEN(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
          Returns TRUE if the file is open (that is, if  it  is  associated
          with an external file), otherwise returns FALSE.
:1404
14.2.2  \uSequential Input-Output\n
The operations available for sequential input and output are  described  in
this  section.   The  \vexception  STATUS_ERROR\v1419.  is  raised  if  any of these
operations is attempted for a \vfile\v1401. that is not open.
    \uprocedure\n READ(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n \vELEMENT_TYPE\v1401.);
          Operates on a file of mode \vIN_FILE\v1401..  Reads an  \velement\v1401.  from  the
          given  file,  and  returns  the value of this element in the ITEM
          parameter.
          The \vexception MODE_ERROR\v1419. is raised if the mode  is  not  IN_FILE.
          The \vexception END_ERROR\v1419. is raised if no more elements can be read
          from  the  given file.  The \vexception DATA_ERROR\v1419. is raised if the
          element read cannot  be  interpreted  as  a  value  of  the  type
          ELEMENT_TYPE;  however, an implementation is allowed to omit this
          check if performing the check is too complex.
    \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE);
          Operates on a file of mode \vOUT_FILE\v1401..  Writes the value of ITEM to
          the given file.
          The  exception  MODE_ERROR is raised if the \vmode\v1401. is not OUT_FILE.
          The \vexception USE_ERROR\v1419. is raised if the capacity of the \vexternal\v1401.
          \vfile\v1401. is exceeded.
    \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
          Operates on a file of mode IN_FILE.   Returns  TRUE  if  no  more
          elements  can  be  read  from  the given file;  otherwise returns
          FALSE.
          The exception MODE_ERROR is raised if the mode is not IN_FILE.
:1405
14.2.3  \uSpecification of the Package Sequential_IO\n
    with \vIO_EXCEPTIONS\v1419.;
    generic
       \utype\n ELEMENT_TYPE \uis private\n;
    \vpackage SEQUENTIAL_IO\v1402. \uis\n
       \utype\n \vFILE_TYPE\v1401. \uis limited private\n;
       \utype\n \vFILE_MODE\v1401. \uis\n (\vIN_FILE\v1401., \vOUT_FILE\v1401.);
       -- File management
       \vprocedure CREATE\v1403.(FILE : \uin out\n FILE_TYPE;
                        MODE : \uin\n FILE_MODE := OUT_FILE;
                        NAME : \uin\n STRING := "";
                        FORM : \uin\n STRING := "");
       \vprocedure OPEN\v1403.  (FILE : \uin out\n FILE_TYPE;
                        MODE : \uin\n FILE_MODE;
                        NAME : \uin\n STRING;
                        FORM : \uin\n STRING := "");
       \vprocedure CLOSE\v1403. (FILE : \uin out\n FILE_TYPE);
       \vprocedure DELETE\v1403.(FILE : \uin out\n FILE_TYPE);
       \vprocedure RESET\v1403. (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE);
       \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE);
       \vfunction MODE\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE;
       \vfunction NAME\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
       \vfunction FORM\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
       \vfunction IS_OPEN\v1403.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
       -- Input and output operations
       \vprocedure READ\v1404.  (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE);
       \vprocedure WRITE\v1404. (FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE);
       \vfunction END_OF_FILE\v1404.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
       -- Exceptions
       \vSTATUS_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR;
       \vMODE_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR;
       \vNAME_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR;
       \vUSE_ERROR\v1419.    : \uexception renames\n IO_EXCEPTIONS.USE_ERROR;
       \vDEVICE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR;
       \vEND_ERROR\v1419.    : \uexception renames\n IO_EXCEPTIONS.END_ERROR;
       \vDATA_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR;
    \uprivate\n
       -- implementation-dependent
    \uend\n SEQUENTIAL_IO;
:1406
14.2.4  \uDirect Input-Output\n
The  operations available for direct input and output are described in this
section.  The \vexception STATUS_ERROR\v1419. is raised if any of  these  operations
is attempted for a \vfile\v1401. that is not \vopen\v1401..
    \uprocedure\n READ(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n \vELEMENT_TYPE\v1401.;
                                        FROM : \uin \n \vPOSITIVE_COUNT\v1408.);
    \uprocedure\n READ(FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE);
          Operates on a file of mode \vIN_FILE\v1401. or \vINOUT_FILE\v1401..  In the case of
          the  first  form, sets the \vcurrent index\v1402. of the given file to the
          \vindex\v1402. value given by the parameter FROM.  Then (for  both  forms)
          returns,  in  the  parameter ITEM, the value of the \velement\v1401. whose
          position in the given file is specified by the current  index  of
          the file;  finally, increases the current index by one.
          The  \vexception MODE_ERROR\v1419. is raised if the \vmode\v1401. of the given file
          is OUT_FILE.  The \vexception END_ERROR\v1419. is raised if the  index  to
          be  used  exceeds  the  size of the \vexternal file\v1401..  The \vexception\v1419.
          \vDATA_ERROR\v1419. is raised if the element read cannot be interpreted as
          a value of the type ELEMENT_TYPE;  however, an implementation  is
          allowed  to  omit  this  check  if  performing  the  check is too
          complex.
    \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE;
                                         TO   : \uin\n POSITIVE_COUNT);
    \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE);
          Operates on a file of mode INOUT_FILE or OUT_FILE.  In  the  case
          of  the first form, sets the index of the given file to the index
          value given by the parameter TO.  Then (for both forms) gives the
          value of the parameter ITEM to the element whose position in  the
          given  file  is  specified  by  the  current  index  of the file;
          finally, increases the current index by one.
          The exception MODE_ERROR is raised if the mode of the given  file
          is IN_FILE.  The \vexception USE_ERROR\v1419. is raised if the capacity of
          the external file is exceeded.
    \uprocedure\n SET_INDEX(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT);
          Operates  on  a  file of any mode.  Sets the current index of the
          given file to the given index value (which may exceed the \vcurrent\v1402.
          \vsize\v1402. of the file).
    \ufunction\n INDEX(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT;
          Operates on a file of any mode.  Returns the current index of the
          given file.
    \ufunction\n SIZE(FILE : \uin\n FILE_TYPE) \ureturn\n \vCOUNT\v1402.;
          Operates on a file of any mode.  Returns the current size of  the
          external file that is associated with the given file.
    \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
          Operates  on  a file of mode IN_FILE or INOUT_FILE.  Returns TRUE
          if the current index exceeds  the  size  of  the  external  file;
          otherwise returns FALSE.
          The  exception MODE_ERROR is raised if the mode of the given file
          is OUT_FILE.
:1407
14.2.5  \uSpecification of the Package Direct_IO\n
    \uwith\n \vIO_EXCEPTIONS\v1419.;
    generic
       \utype\n \vELEMENT_TYPE\v1406. \uis private\n;
    \upackage\n DIRECT_IO \uis\n
       \utype\n \vFILE_TYPE\v1406. \uis limited private\n;
       \utype\n FILE_MODE \uis\n (\vIN_FILE\v1406., \vINOUT_FILE\v1406., \vOUT_FILE\v1403.);
       \vtype    COUNT\v1402.     \uis range\n 0 .. implementation defined;
       \usubtype\n POSITIVE_COUNT \uis\n COUNT \urange\n 1 .. COUNT'LAST;
       -- File management
       \vprocedure CREATE\v1403.(FILE : \uin out\n FILE_TYPE;
                        MODE : \uin\n FILE_MODE := INOUT_FILE;
                        NAME : \uin\n STRING := "";
                        FORM : \uin\n STRING := "");
       \vprocedure OPEN\v1403.  (FILE : \uin out\n FILE_TYPE;
                        MODE : \uin\n FILE_MODE;
                        NAME : \uin\n STRING;
                        FORM : \uin\n STRING := "");
       \vprocedure CLOSE\v1403. (FILE : \uin out\n FILE_TYPE);
       \vprocedure DELETE\v1403.(FILE : \uin out\n FILE_TYPE);
       \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE; MODE : \uin\n FILE_MODE);
       \uprocedure\n RESET (FILE : \uin out\n FILE_TYPE);
       \vfunction MODE\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n FILE_MODE;
       \vfunction NAME\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
       \vfunction FORM\v1403.   (FILE : \uin\n FILE_TYPE) \ureturn\n STRING;
       \vfunction IS_OPEN\v1403.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
       -- Input and output operations
       \vprocedure READ\v1406. (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE; FROM :
        POSITIVE_COUNT);
       \uprocedure\n READ (FILE : \uin\n FILE_TYPE; ITEM : \uout\n ELEMENT_TYPE);
       \vprocedure WRITE\v1406.(FILE : \uin\n FILE_TYPE; ITEM : \uin \n ELEMENT_TYPE; TO :
        POSITIVE_COUNT);
       \uprocedure\n WRITE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n ELEMENT_TYPE);
       \vprocedure SET_INDEX\v1406.(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT);
       \vfunction INDEX\v1406.(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT;
       \vfunction SIZE\v1406. (FILE : \uin\n FILE_TYPE) \ureturn\n COUNT;
       \vfunction END_OF_FILE\v1406.(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
       -- Exceptions
       \vSTATUS_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR;
       \vMODE_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR;
       \vNAME_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR;
       \vUSE_ERROR\v1419.    : \uexception renames\n IO_EXCEPTIONS.USE_ERROR;
       \vDEVICE_ERROR\v1419. : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR;
       \vEND_ERROR\v1419.    : \uexception renames\n IO_EXCEPTIONS.END_ERROR;
       \vDATA_ERROR\v1419.   : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR;
    \uprivate\n
       -- implementation-dependent
    \uend\n DIRECT_IO;
:1408
14.3  \uText Input-Output\n
This  section  describes the package TEXT_IO, which provides facilities for
input and output in human-readable form.  Each  \vfile\v1401.  is  \vread\v1404.  or  written
sequentially,  as  a  sequence  of  characters grouped into lines, and as a
sequence of lines grouped into pages.  The specification of the package  is
given below in section 14.3.10.
The  facilities  for  file  management  given above, in sections 14.2.1 and
14.2.2, are available for text input-output.  In place of READ  and  WRITE,
however,  there  are  procedures  \vGET\v1413. and \vPUT\v1413. that input values of suitable
types from text files,  and  output  values  to  them.   These  values  are
provided  to  the  PUT procedures, and returned by the GET procedures, in a
parameter ITEM.  Several overloaded procedures of these  names  exist,  for
different  types of ITEM.  These GET procedures analyze the input sequences
of  characters  as  lexical  elements  (see  Chapter  2)  and  return   the
corresponding  values;   the  PUT  procedures  output  the  given values as
appropriate lexical elements.  Procedures GET and PUT  are  also  available
that  input  and  output  individual characters treated as character values
rather than as lexical elements.
In addition to the procedures GET and PUT for numeric and enumeration types
of ITEM that operate on text files, analogous procedures are provided  that
read  from  and  write  to  a  parameter  of type STRING.  These procedures
perform the same analysis and composition of character sequences  as  their
counterparts which have a file parameter.
For  all  GET  and  PUT procedures that operate on text files, and for many
other subprograms, there are forms with and without a file parameter.  Each
such GET procedure operates on an input file, and each such  PUT  procedure
operates  on an output file.  If no file is specified, a default input file
or a default output file is used.
At the beginning of program execution the default input  and  output  files
are  the  so-called  \vstandard  input  file\v1410. and \vstandard output file\v1410..  These
files are open, have respectively the current modes \vIN_FILE\v1401.  and  \vOUT_FILE\v1401.,
and   are   associated  with  two  implementation-defined  \vexternal  files\v1401..
Procedures are provided to change the \vcurrent default input  file\v1410.  and  the
\vcurrent default output file\v1410..
From a logical point of view, a text file is a sequence of pages, a page is
a  sequence of lines, and a line is a sequence of characters;  the end of a
line is marked by a line terminator;  the end of a page is  marked  by  the
combination of a line terminator immediately followed by a page terminator;
and  the  end  of  a file is marked by the combination of a line terminator
immediately followed by a page  terminator  and  then  a  file  terminator.
Terminators  are  generated  during  output;  either by calls of procedures
provided expressly for that  purpose;   or  implicitly  as  part  of  other
operations, for example, when a bounded line length, a bounded page length,
or both, have been specified for a file.
The  actual  nature of terminators is not defined by the language and hence
depends on the implementation.   Although  terminators  are  recognized  or
generated   by  certain  of  the  procedures  that  follow,  they  are  not
necessarily implemented  as  characters  or  as  sequences  of  characters.
Whether  they  are  characters  (and  if  so  which ones) in any particular
implementation need not concern a user who neither explicitly  outputs  nor
explicitly  inputs  control  characters.   The effect of input or output of
control characters (other than horizontal tabulation) is not defined by the
language.
The characters of a line are numbered, starting from one;  the number of  a
character  is  called  its  column number.  For a line terminator, a column
number is also defined:  it is one more than the number  of  characters  in
the  line.   The  lines  of  a page, and the pages of a file, are similarly
numbered.  The current column number is  the  column  number  of  the  next
character or line terminator to be transferred.  The current line number is
the  number  of the current line.  The current page number is the number of
the current page.  These numbers are values of the  subtype  POSITIVE_COUNT
of  the \vtype COUNT\v1418. (by convention, the value zero of the type COUNT is used
to indicate special conditions).
    type COUNT is range 0 .. implementation_defined;
    subtype POSITIVE_COUNT is COUNT range 1 .. COUNT'LAST;
For an output file, a maximum line length can be specified  and  a  maximum
page  length  can  be specified.  If a value to be output cannot fit on the
current line, for a specified maximum line  length,  then  a  new  line  is
automatically  started  before  the value is output;  if, further, this new
line cannot fit on the current page, for a specified maximum  page  length,
then  a  new  page  is  automatically  started  before the value is output.
Functions are provided to determine the maximum line length and the maximum
page length.  When a file is opened with mode  OUT_FILE,  both  values  are
zero:  by convention, this means that the line lengths and page lengths are
unbounded.   (Consequently,  output  consists  of  a  single  line  if  the
subprograms for explicit control of line and page structure are not  used.)
The constant UNBOUNDED is provided for this purpose.
More details:
 14.3.1  \vFile Management\v1409.
 14.3.2  \vDefault Input and Output Files\v1410.
 14.3.3  \vSpecification of Line and Page Lengths\v1411.
 14.3.4  \vOperations on Columns, Lines and Pages\v1412.
 14.3.5  \vGET and PUT Procedures\v1413.
 14.3.6  \vInput-output of Characters and Strings\v1414.
 14.3.7  \vInput-Output for Integer Types\v1415.
 14.3.8  \vInput-Output for Real Types\v1416.
 14.3.9  \vInput-Output for Enumeration Types\v1417.
 14.3.10 \vSpecification of the Package TEXT_IO\v1418.
:1409
14.3.1  \uFile Management\n
The only allowed \vfile modes\v1401. for  text  \vfiles\v1401.  are  the  modes  \vIN_FILE\v1401.  and
\vOUT_FILE\v1401..   The  subprograms  given  in  section  14.2.1 for the control of
\vexternal files\v1401., and the function \vEND_OF_FILE\v1408. given in  section  14.2.2  for
sequential  input-output, are also available for text files.  There is also
a version of END_OF_FILE that refers to the  \vcurrent  default  input  file\v1408..
For text files, the procedures have the following additional effects:
  -  For the procedures \vCREATE\v1403. and \vOPEN\v1403.:  After opening a  file  with  mode
     OUT_FILE, the \vpage length\v1408. and \vline length\v1408. are unbounded (both have the
     conventional  value  zero).  After opening a file with mode IN_FILE or
     OUT_FILE, the \vcurrent column\v1408., \vcurrent line\v1408., and \vcurrent  page  numbers\v1408.
     are set to one.
  -  For the procedure CLOSE:  If the file has the current  mode  OUT_FILE,
     has the effect of calling NEW_PAGE, unless the current page is already
     terminated; then outputs a \vfile terminator\v1408..
  -  For the \vprocedure RESET\v1403.:  If the file has the current  mode  OUT_FILE,
     has the effect of calling NEW_PAGE, unless the current page is already
     terminated;   then outputs a file terminator.  If the new file mode is
     OUT_FILE, the page and line lengths are unbounded.  For all modes, the
     current column, line, and page numbers are set to one.
The \vexception MODE_ERROR\v1419. is raised by the procedure RESET upon  an  attempt
to change the mode of a file that is either the current default input file,
or the current default output file.
:1410
14.3.2  \uDefault Input and Output Files\n
The following subprograms provide for the control of the particular \vdefault\v1408.
\vfiles\v1408. that are used when a file parameter is omitted from  a  \vGET\v1413.,  \vPUT\v1413.  or
other operation of text input-output described below.
    \uprocedure\n SET_INPUT(FILE : \uin\n \vFILE_TYPE\v1401.);
          Operates  on  a  file  of mode IN_FILE.  Sets the current default
          input file to FILE.
          The \vexception STATUS_ERROR\v1419. is raised if the  given  file  is  not
          open.   The  \vexception  MODE_ERROR\v1419.  is  raised if the mode of the
          given file is not IN_FILE.
    \uprocedure\n SET_OUTPUT(FILE : \uin\n FILE_TYPE);
          Operates on a file of mode OUT_FILE.  Sets  the  current  default
          output file to FILE.
          The  exception  STATUS_ERROR  is  raised if the given file is not
          open.  The exception MODE_ERROR is raised  if  the  mode  of  the
          given file is not OUT_FILE.
    \ufunction\n STANDARD_INPUT \ureturn\n FILE_TYPE;
          Returns the standard input file (see 14.3).
    \ufunction\n STANDARD_OUTPUT \ureturn\n FILE_TYPE;
          Returns the standard output file (see 14.3).
    \ufunction\n CURRENT_INPUT \ureturn\n FILE_TYPE;
          Returns the current default input file.
    \ufunction\n CURRENT_OUTPUT \ureturn\n FILE_TYPE;
          Returns the current default output file.
Note:
The  standard input and the standard output files cannot be opened, closed,
reset,  or  deleted,  because  the  parameter  FILE  of  the  corresponding
procedures has the mode in out.
:1411
14.3.3  \uSpecification of Line and Page Lengths\n
The  subprograms  described in this section are concerned with the \vline\v1408. and
\vpage\v1408. structure of a \vfile\v1401. of mode \vOUT_FILE\v1401..  They operate either on the file
given as the first parameter, or, in the absence of such a file  parameter,
on the \vcurrent default output file\v1408..  They provide for output of text with a
specified  \vmaximum  line  length\v1408.  or \vpage length\v1408..  In these cases, \vline\v1408. and
\vpage terminators\v1408. are output implicitly and automatically when needed.  When
\vline\v1408.  and  \vpage  lengths\v1408.  are  unbounded  (that  is,  when  they  have  the
conventional  value zero), as in the case of a newly opened file, new lines
and new pages are only started when explicitly called for.
In all cases, the \vexception STATUS_ERROR\v1419. is raised if the file to  be  used
is  not \vopen\v1401.; the \vexception MODE_ERROR\v1419. is raised if the mode of the file is
not OUT_FILE.
    \uprocedure\n SET_LINE_LENGTH(FILE : \uin\n \vFILE_TYPE\v1401.; TO : \uin\n \vCOUNT\v1408.);
    \uprocedure\n SET_LINE_LENGTH(TO   : \uin\n COUNT);
          Sets the maximum line length of the specified output file to  the
          number  of  characters  specified  by  TO.  The value zero for TO
          specifies an unbounded line length.
          The \vexception USE_ERROR\v1419. is raised if the specified line length is
          inappropriate for the associated \vexternal file\v1401..
    \uprocedure\n SET_PAGE_LENGTH(FILE : \uin\n FILE_TYPE; TO : \uin\n COUNT);
    \uprocedure\n SET_PAGE_LENGTH(TO   : \uin\n COUNT);
          Sets the maximum page length of the specified output file to  the
          number of lines specified by TO.  The value zero for TO specifies
          an \vunbounded page length\v1408..
          The exception USE_ERROR is raised if the specified page length is
          inappropriate for the associated external file.
    \ufunction\n LINE_LENGTH(FILE : \uin\n FILE_TYPE) \ureturn\n COUNT;
    \ufunction\n LINE_LENGTH \ureturn\n COUNT;
          Returns  the  maximum line length currently set for the specified
          output file, or zero if the line length is unbounded.
    \ufunction\n PAGE_LENGTH(FILE : \uin\n FILE_TYPE) \ureturn\n COUNT;
    \ufunction\n PAGE_LENGTH \ureturn\n COUNT;
          Returns the maximum page length currently set for  the  specified
          output file, or zero if the page length is unbounded.
:1412
14.3.4  \uOperations on Columns, Lines, and Pages\n
The subprograms described in this section provide for explicit  control  of
\vline\v1408.  and  \vpage\v1408.  structure;   they  operate either on the \vfile\v1401. given as the
first parameter, or, in the absence  of  such  a  file  parameter,  on  the
appropriate   (input  or  output)  \vcurrent  default  file\v1408..   The  \vexception\v1419.
\vSTATUS_ERROR\v1419. is raised by any of these subprograms if the file to  be  used
is not \vopen\v1401..
    \uprocedure\n NEW_LINE(FILE : \uin\n FILE_TYPE; SPACING :
              \uin\n \vPOSITIVE_COUNT\v1408. := 1);
    \uprocedure\n NEW_LINE(SPACING : \uin\n POSITIVE_COUNT := 1);
          Operates on a file of mode OUT_FILE.
          For  a  SPACING  of  one:  Outputs a \vline terminator\v1408. and sets the
          \vcurrent column number\v1408. to one.  Then increments the  \vcurrent  line\v1408.
          \vnumber\v1408. by one, except in the case that the current \vline number\v1408. is
          already  greater  than or equal to the \vmaximum page length\v1408., for a
          bounded \vpage length\v1408.;  in that case a \vpage terminator\v1408.  is  output,
          the  \vcurrent  page  number\v1408. is incremented by one, and the current
          line number is set to one.
          For a SPACING greater than one, the above actions  are  performed
          SPACING times.
          The  \vexception  MODE_ERROR\v1419. is raised if the mode is not OUT_FILE.
 \uprocedure\n SKIP_LINE(FILE  : \uin\n FILE_TYPE; SPACING :
           \uin\n POSITIVE_COUNT := 1);
 \uprocedure\n SKIP_LINE(SPACING : \uin\n POSITIVE_COUNT := 1);
          Operates on a file of mode \vIN_FILE\v1401..
          For a SPACING of one:  Reads and discards all characters until  a
          line  terminator  has been read, and then sets the current column
          number to  one.   If  the  line  terminator  is  not  immediately
          followed  by  a  page  terminator,  the  current  line  number is
          incremented  by  one.   Otherwise,  if  the  line  terminator  is
          immediately   followed  by  a  page  terminator,  then  the  page
          terminator is skipped, the current page number is incremented  by
          one, and the current line number is set to one.
          For  a  SPACING greater than one, the above actions are performed
          SPACING times.
          The exception MODE_ERROR is raised if the mode  is  not  IN_FILE.
          The \vexception END_ERROR\v1419. is raised if an attempt is made to read a
          \vfile terminator\v1408..
    \ufunction\n END_OF_LINE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
    \ufunction\n END_OF_LINE \ureturn\n BOOLEAN;
          Operates  on  a  file  of  mode IN_FILE.  Returns TRUE if  a line
          terminator or a  file  terminator  is  next;   otherwise  returns
          FALSE.
          The exception MODE_ERROR is raised if the mode is not IN_FILE.
    \uprocedure\n NEW_PAGE(FILE : \uin\n FILE_TYPE);
    \uprocedure\n NEW_PAGE;
          Operates  on  a file of mode OUT_FILE.  Outputs a line terminator
          if the current line is not terminated, or if the current page  is
          empty  (that  is, if the current column and line numbers are both
          equal to one).  Then outputs a page terminator, which  terminates
          the  current  page.  Adds one to the current page number and sets
          the current column and line numbers to one.
          The exception MODE_ERROR is raised if the mode is  not  OUT_FILE.
    \uprocedure\n SKIP_PAGE(FILE: \uin\n FILE_TYPE);
    \uprocedure\n SKIP_PAGE;
          Operates  on  a  file  of  mode  IN_FILE.  Reads and discards all
          characters and line terminators until a page terminator has  been
          read.   Then  adds  one  to the current page number, and sets the
          current column and line numbers to one.
          The exception MODE_ERROR is raised if the mode  is  not  IN_FILE.
          The exception END_ERROR is raised if an attempt is made to read a
          file terminator.
    \ufunction\n END_OF_PAGE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
    \ufunction\n END_OF_PAGE \ureturn\n BOOLEAN;
          Operates  on  a  file  of  mode  IN_FILE.   Returns  TRUE  if the
          combination of a line terminator and a page terminator  is  next,
          or if a file terminator is next;  otherwise returns FALSE.
          The exception MODE_ERROR is raised if the mode is not IN_FILE.
    \ufunction\n END_OF_FILE(FILE : \uin\n FILE_TYPE) \ureturn\n BOOLEAN;
    \ufunction\n END_OF_FILE \ureturn\n BOOLEAN;
          Operates  on  a  file  of  mode  IN_FILE.  Returns TRUE if a file
          terminator is next, or if the combination of a line, a page,  and
          a file terminator is next;  otherwise returns FALSE.
          The exception MODE_ERROR is raised if the mode is not IN_FILE.
The  following  subprograms provide for the control of the current position
of reading or writing in a file.  In all cases, the  default  file  is  the
current output file.
    \uprocedure\n SET_COL(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT);
    \uprocedure\n SET_COL(TO   : \uin\n POSITIVE_COUNT);
          If the file mode is OUT_FILE:
               If  the  value  specified  by TO is greater than the current
               column number, outputs spaces, adding  one  to  the  current
               column  number  after  each  space, until the current column
               number equals the specified value.  If the  value  specified
               by  TO  is  equal  to the current column number, there is no
               effect.  If the value specified  by  TO  is  less  than  the
               current  column  number,  has the effect of calling NEW_LINE
               (with a spacing of one), then outputs (TO - 1)  spaces,  and
               sets the current column number to the specified value.
               The  \vexception LAYOUT_ERROR\v1419. is raised if the value specified
               by TO exceeds LINE_LENGTH when the line  length  is  bounded
               (that  is,  when  it  does  not  have the conventional value
               zero).
          If the file mode is IN_FILE:
               Reads   (and   discards)   individual    characters,    line
               terminators,  and page terminators, until the next character
               to be read  has  a  column  number  that  equals  the  value
               specified  by  TO;  there is no effect if the current column
               number already  equals  this  value.   Each  transfer  of  a
               character  or terminator maintains the current column, line,
               and page numbers in the same way as  a  \vGET  procedure\v1413.  (see
               14.3.5).   (Short  lines  will  be  skipped  until a line is
               reached  that  has  a  character  at  the  specified  column
               position.)
               The  exception  END_ERROR is raised if an attempt is made to
               read a file terminator.
    \uprocedure\n SET_LINE(FILE : \uin\n FILE_TYPE; TO : \uin\n POSITIVE_COUNT);
    \uprocedure\n SET_LINE(TO   : \uin\n POSITIVE_COUNT);
          If the file mode is OUT_FILE:
               If the value specified by TO is  greater  than  the  current
               line  number,  has the effect of repeatedly calling NEW_LINE
               (with a spacing of  one),  until  the  current  line  number
               equals the specified value.  If the value specified by TO is
               equal  to  the  current line number, there is no effect.  If
               the value specified by TO is  less  than  the  current  line
               number,  has  the  effect  of calling NEW_PAGE followed by a
               call of NEW_LINE with a spacing equal to (TO - 1).
               The exception LAYOUT_ERROR is raised if the value  specified
               by  TO  exceeds  PAGE_LENGTH when the page length is bounded
               (that is, when it  does  not  have  the  conventional  value
               zero).
          If the mode is IN_FILE:
               Has  the  effect  of  repeatedly  calling  SKIP_LINE (with a
               spacing of one), until the current line  number  equals  the
               value  specified  by  TO;  there is no effect if the current
               line number already equals this value.  (Short pages will be
               skipped until a page is reached  that  has  a  line  at  the
               specified line position.)
               The  exception  END_ERROR is raised if an attempt is made to
               read a file terminator.
    \ufunction\n COL(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT;
    \ufunction\n COL \ureturn\n POSITIVE_COUNT;
          Returns the current column number.
          The exception LAYOUT_ERROR  is  raised  if  this  number  exceeds
          COUNT'LAST.
    \ufunction\n LINE(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT;
    \ufunction\n LINE \ureturn\n POSITIVE_COUNT;
          Returns the current line number.
          The  exception  LAYOUT_ERROR  is  raised  if  this number exceeds
          COUNT'LAST.
    \ufunction\n PAGE(FILE : \uin\n FILE_TYPE) \ureturn\n POSITIVE_COUNT;
    \ufunction\n PAGE \ureturn\n POSITIVE_COUNT;
          Returns the current page number.
          The exception LAYOUT_ERROR  is  raised  if  this  number  exceeds
          COUNT'LAST.
The  column  number,  line  number,  or  page  number are allowed to exceed
COUNT'LAST (as a consequence of the input or output  of  sufficiently  many
characters,  lines,  or pages).  These events do not cause any exception to
be raised.  However, a call of COL, LINE,  or  PAGE  raises  the  exception
LAYOUT_ERROR if the corresponding number exceeds COUNT'LAST.
Note:
A  page terminator is always skipped whenever the preceding line terminator
is skipped.  An implementation  may  represent  the  combination  of  these
terminators  by a single character, provided that it is properly recognized
at input.
:1413
14.3.5  \uGet and Put Procedures\n
The  procedures  \vGET\v1414.  and  \vPUT\v1414.  for  items  of the types CHARACTER, STRING,
numeric types, and enumeration types are described in subsequent  sections.
Features  of  these  procedures  that are common to most of these types are
described in this section.  The GET and PUT procedures for  items  of  type
CHARACTER  and  STRING  deal with individual character values;  the GET and
PUT procedures for numeric and enumeration types treat the items as lexical
elements.
All procedures GET and PUT have forms with a file parameter, written first.
Where this parameter is omitted, the appropriate (input or output)  \vcurrent\v1408.
\vdefault file\v1408. is understood to be specified.  Each procedure GET operates on
a  \vfile\v1401.  of  mode  \vIN_FILE\v1401..   Each procedure PUT operates on a file of mode
\vOUT_FILE\v1401..
All procedures GET and PUT maintain the  current  column,  line,  and  page
numbers of the specified file:  the effect of each of these procedures upon
these  numbers  is  the resultant of the effects of individual transfers of
characters and of individual  output  or  \vskipping\v1415.  of  terminators.   Each
transfer of a character adds one to the current \vcolumn number\v1408..  Each output
of  a \vline terminator\v1401. sets the current column number to one and adds one to
the current \vline number\v1401..   Each  output  of  a  \vpage  terminator\v1401.  sets  the
current  column  and  line  numbers to one and adds one to the current \vpage\v1401.
\vnumber\v1401..  For input, each skipping of a line  terminator  sets  the  current
column  number  to  one  and  adds  one  to  the current line number;  each
skipping of a page terminator sets the current column and line  numbers  to
one  and adds one to the current page number.  Similar considerations apply
to the procedures GET_LINE, PUT_LINE, and SET_COL.
Several GET and PUT procedures, for numeric  and  enumeration  types,  have
format parameters which specify field lengths;  these parameters are of the
nonnegative subtype FIELD of the type INTEGER.
Input-output  of  enumeration  values  uses the syntax of the corresponding
lexical elements.  Any GET procedure for  an  enumeration  type  begins  by
skipping  any  leading  \vblanks\v1417., or line or page terminators;  a blank being
defined as a space or a horizontal tabulation character.  Next,  characters
are  input  only so long as the sequence input is an initial sequence of an
identifier or of a character literal (in particular, input  ceases  when  a
line  terminator  is  encountered).   The character or line terminator that
causes input to cease remains available for subsequent input.
For a numeric type, the GET  procedures  have  a  format  parameter  called
\vWIDTH\v1413..   If  the  value given for this parameter is zero, the GET procedure
proceeds in the same manner as for enumeration types, but using the  syntax
of  numeric literals instead of that of enumeration literals.  If a nonzero
value is given, then exactly WIDTH characters are input, or the  characters
up to a line terminator, whichever comes first;  any skipped leading blanks
are  included  in  the  count.   The syntax used for numeric literals is an
extended syntax that allows a leading sign (but no intervening  blanks,  or
line or page terminators).
Any PUT procedure, for an item of a numeric or an enumeration type, outputs
the  value  of  the  item  as  a  numeric literal, identifier, or character
literal, as appropriate.  This is preceded by leading spaces if required by
the format parameters WIDTH or \vFORE\v1416. (as described in later  sections),  and
then  a  minus  sign  for  a  negative value;  for an enumeration type, the
spaces follow instead of leading.  The format given for a PUT procedure  is
overridden if it is insufficiently wide.
Two  further  cases  arise  for  PUT procedures for numeric and enumeration
types, if the line length of the specified output file is bounded (that is,
if it does not have  the  conventional  value  zero).   If  the  number  of
characters  to  be  output  does not exceed the \vmaximum line length\v1408., but is
such that they cannot fit on the current line, starting  from  the  current
column,  then (in effect) NEW_LINE is called (with a spacing of one) before
output of the item.  Otherwise, if the number  of  characters  exceeds  the
maximum  line  length,  then  the  \vexception  LAYOUT_ERROR\v1419. is raised and no
characters are output.
The \vexception  STATUS_ERROR\v1419.  is  raised  by  any  of  the  procedures  GET,
GET_LINE,  PUT,  and  PUT_LINE  if  the  file  to be used is not open.  The
\vexception MODE_ERROR\v1419. is raised by the procedures GET and  GET_LINE  if  the
\vmode\v1401.  of the file to be used is not IN_FILE;  and by the procedures PUT and
PUT_LINE, if the mode is not OUT_FILE.
The \vexception END_ERROR\v1419. is raised by a GET procedure if an attempt is  made
to  skip  a  file  terminator.  The \vexception DATA_ERROR\v1419. is raised by a GET
procedure  if  the  sequence  finally  input  is  not  a  lexical   element
corresponding  to the type, in particular if no characters were input;  for
this test, leading blanks are ignored;  for an item of a numeric type, when
a sign is input, this rule applies to the succeeding numeric literal.   The
exception  LAYOUT_ERROR  is  raised  by  a  PUT procedure that outputs to a
parameter  of  type  STRING,  if  the  length  of  the  actual  string   is
insufficient for the output of the item.
\uExamples:\n
In  the examples, here and in sections 14.3.7 and 14.3.8, the string quotes
and the lower case letter b are not transferred:  they are  shown  only  to
reveal the layout and spaces.
    N : INTEGER;
       ...
    GET(N);
    -- Characters at input      Sequence input     Value of N
    --      bb-12535b           -12535             -12535
    --      bb12_535E1b          12_535E1           125350
    --      bb12_535E;           12_535E           (none) DATA_ERROR raised
Example of overridden width parameter:
    PUT(ITEM => -23, WIDTH => 2);  --  "-23"
:1414
14.3.6  \uInput-Output of Characters and Strings\n
For an item of type CHARACTER the following procedures are provided:
    \vprocedure GET\v1413.(\vFILE\v1401. : in FILE_TYPE; ITEM : out CHARACTER);
    procedure GET(ITEM : out CHARACTER);
          After \vskipping\v1413. any line terminators  and  any  \vpage  terminators\v1408.,
          reads  the  next  character  from  the  specified  input file and
          returns the value of this character in the out parameter ITEM.
          The \vexception END_ERROR\v1419. is raised if an attempt is made to skip a
          \vfile terminator\v1408..
    \vprocedure PUT\v1412.(FILE : in FILE_TYPE; ITEM : in CHARACTER);
    procedure PUT(ITEM : in CHARACTER);
          If the \vline length\v1408. of the specified output file is bounded  (that
          is,  does  not have the conventional value zero), and the \vcurrent\v1408.
          \vcolumn number\v1408. exceeds it, has the effect of calling NEW_LINE with
          a  spacing  of  one.   Then,  or  otherwise,  outputs  the  given
          character to the file.
For an item of type STRING the following procedures are provided:
    \uprocedure\n GET(FILE : \uin\n FILE_TYPE; ITEM : \uout\n STRING);
    \uprocedure\n GET(ITEM : \uout\n STRING);
          Determines  the  length  of  the  given  string and attempts that
          number of GET operations for successive characters of the  string
          (in particular, no operation is performed if the string is null).
    \uprocedure\n PUT(FILE : \uin\n FILE_TYPE; ITEM : \uin\n STRING);
    \uprocedure\n PUT(ITEM : \uin\n STRING);
          Determines  the  length  of  the  given  string and attempts that
          number of PUT operations for successive characters of the  string
          (in particular, no operation is performed if the string is null).
\uprocedure\n GET_LINE(FILE : \uin\n FILE_TYPE; ITEM : \uout\n STRING; LAST :
          \uout\n NATURAL);
\uprocedure\n GET_LINE(ITEM : \uout\n STRING;   LAST : \uout\n NATURAL);
          Replaces   successive  characters  of  the  specified  string  by
          successive  characters  read  from  the  specified  input   file.
          Reading  stops  if  the end of the \vline\v1408. is met, in which case the
          procedure SKIP_LINE is then called (in effect) with a spacing  of
          one;   reading  also  stops  if  the  end  of  the string is met.
          Characters not replaced are left undefined.
          If characters are read, returns in LAST the index value such that
          ITEM(LAST) is the last character replaced (the index of the first
          character replaced is ITEM'FIRST).  If no  characters  are  read,
          returns  in LAST an index value that is one less than ITEM'FIRST.
          The exception END_ERROR is raised if an attempt is made to skip a
          file terminator.
    \uprocedure\n PUT_LINE(FILE : \uin\n FILE_TYPE; ITEM : \uin\n STRING);
    \uprocedure\n PUT_LINE(ITEM : \uin\n STRING);
          Calls the procedure PUT  for  the  given  string,  and  then  the
          \vprocedure NEW_LINE\v1412. with a spacing of one.
\uNotes:\n
In  a  literal  string  parameter  of  PUT,  the  enclosing  string bracket
characters are not output.  Each doubled string bracket  character  in  the
enclosed  string  is  output  as  a  single  string bracket character, as a
consequence of the rule for string literals (see 2.6).
A string read by GET or written by PUT can extend over several lines.
:1415
14.3.7  \uInput-Output for Integer Types\n
The  following  procedures  are  defined in the generic \vpackage INTEGER_IO\v1418..
This must be instantiated for the appropriate integer  type  (indicated  by
NUM in the specification).
Values   are  output  as  \vdecimal\v205.  or  \vbased  literals\v206.,  without  underline
characters or exponent, and preceded by a  minus  sign  if  negative.   The
format  (which includes any leading spaces and minus sign) can be specified
by an optional field \vwidth\v1413. parameter.  Values of widths of fields in output
formats are of the nonnegative integer subtype \vFIELD\v1413..  Values of bases  are
of the integer subtype NUMBER_BASE.
    \usubtype\n NUMBER_BASE \uis\n INTEGER \urange\n 2 .. 16;
The  default  field  width  and  base  to  be used by output procedures are
defined by the following variables that are declared in the generic package
INTEGER_IO:
    DEFAULT_WIDTH : FIELD := NUM'WIDTH;
    DEFAULT_BASE  : NUMBER_BASE := 10;
The following procedures are provided:
 \vprocedure GET\v1413.(FILE : in \vFILE_TYPE\v1401.; ITEM : out NUM; WIDTH : in FIELD := 0);
 procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0);
          If the value of the parameter WIDTH is zero,  skips  any  leading
          \vblanks\v1413.,  \vline terminators\v1408., or page terminators, then reads a plus
          or a minus sign if present, then reads according to the syntax of
          an \vinteger literal\v204. (which may be a based literal).  If a  nonzero
          value  of  WIDTH  is  supplied, then exactly WIDTH characters are
          input, or the characters (possibly none) up to a line terminator,
          whichever comes first;  any skipped leading blanks  are  included
          in the count.
          Returns,  in  the  parameter  ITEM,  the  value  of type NUM that
          corresponds to the sequence input.
          The \vexception DATA_ERROR\v1419. is raised if the sequence input does not
          have the required syntax or if the value obtained is not  of  the
          subtype NUM.
    \vprocedure PUT\v1413.(FILE  : \uin\n FILE_TYPE;
                  ITEM  : \uin\n NUM;
                  WIDTH : \uin\n FIELD := DEFAULT_WIDTH;
                  BASE  : \uin\n NUMBER_BASE := DEFAULT_BASE);
    \uprocedure\n PUT(ITEM  : \uin\n NUM;
                  WIDTH : \uin\n FIELD := DEFAULT_WIDTH;
                  BASE  : \uin\n NUMBER_BASE := DEFAULT_BASE);
          Outputs  the  value  of the parameter ITEM as an integer literal,
          with no underlines, no exponent, and  no  leading  zeros  (but  a
          single zero for the value zero), and a preceding minus sign for a
          negative value.
          If  the  resulting  sequence of characters to be output has fewer
          than WIDTH characters, then leading spaces are  first  output  to
          make up the difference.
          Uses the syntax for decimal literal if the parameter BASE has the
          value   ten   (either   explicitly   or   through  DEFAULT_BASE);
          otherwise, uses the syntax for based literal, with any letters in
          upper case.
    procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE);
          Reads an integer value from the beginning of  the  given  string,
          following  the  same  rules  as  the  GET procedure that reads an
          integer value from a file, but treating the end of the string  as
          a  file terminator.  Returns, in the parameter ITEM, the value of
          type NUM that corresponds to the sequence input.  Returns in LAST
          the index value such that FROM(LAST) is the last character  read.
          The exception DATA_ERROR is raised if the sequence input does not
          have  the  required syntax or if the value obtained is not of the
          subtype NUM.
    \uprocedure\n PUT(TO   : \uout\n STRING;
                  ITEM : \uin\n NUM;
                  BASE : \uin\n NUMBER_BASE := DEFAULT_BASE);
          Outputs the value of the parameter  ITEM  to  the  given  string,
          following the same rule as for output to a file, using the length
          of the given string as the value for WIDTH.
\uExamples:\n
    \upackage\n INT_IO \uis new\n INTEGER_IO(SMALL_INT); \uuse\n INT_IO;
    -- default format used at instantiation,
         DEFAULT_WIDTH = 4, DEFAULT_BASE = 10
    PUT(126);                            -- "b126"
    PUT(-126, 7);                        -- "bbb-126"
    PUT(126, WIDTH => 13, BASE => 2);    -- "bbb2#1111110#"
:1416
14.3.8  \uInput-Output for Real Types\n
The  following  procedures are defined in the generic packages \vFLOAT_IO\v1418. and
\vFIXED_IO\v1418., which must be instantiated for the appropriate floating point  or
fixed point type respectively (indicated by NUM in the specifications).
Values  are  output  as \vdecimal literals\v205. without underline characters.  The
format of each value output consists of a \vFORE\v320. field, a decimal  point,  an
\vAFT\v320. field, and (if a nonzero EXP parameter is supplied) the letter E and an
EXP field.  The two possible formats thus correspond to:
    FORE  .  AFT
and to:
    FORE  .  AFT  E  EXP
without  any  spaces  between  these  fields.   The  FORE field may include
leading spaces, and a minus sign  for  negative  values.    The  AFT  field
includes only decimal digits (possibly with trailing zeros).  The EXP field
includes  the  sign (plus or minus) and the exponent (possibly with leading
zeros).
For floating point types, the default lengths of these fields  are  defined
by  the  following  variables  that  are  declared  in  the generic package
FLOAT_IO:
    DEFAULT_FORE : \vFIELD\v1413. := 2;
    DEFAULT_AFT  : FIELD := NUM'DIGITS-1;
    DEFAULT_EXP  : FIELD := 3;
For fixed point types, the default lengths of these fields are  defined  by
the  following variables that are declared in the generic package FIXED_IO:
    DEFAULT_FORE : FIELD := NUM'FORE;
    DEFAULT_AFT  : FIELD := NUM'AFT;
    DEFAULT_EXP  : FIELD := 0;
The following procedures are provided:
 \vprocedure GET\v1413.(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n NUM; \vWIDTH\v1413. : \uin\n FIELD := 0);
 \uprocedure\n GET(ITEM : \uout\n NUM; WIDTH : \uin\n FIELD := 0);
          If the value of the parameter WIDTH is zero,  skips  any  leading
          \vblanks\v1413.,  \vline terminators\v1413., or page terminators, then reads a plus
          or a minus sign if present, then reads according to the syntax of
          a \vreal literal\v204. (which may be a  \vbased  literal\v206.).   If  a  nonzero
          value  of  WIDTH  is  supplied, then exactly WIDTH characters are
          input, or the characters (possibly none) up to a line terminator,
          whichever comes first;  any skipped leading blanks  are  included
          in the count.
          Returns,  in  the  parameter  ITEM,  the  value  of type NUM that
          corresponds to the sequence input.
          The \vexception DATA_ERROR\v1413. is raised if the sequence input does not
          have the required syntax or if the value obtained is not  of  the
          subtype NUM.
    \vprocedure PUT\v1413.(FILE : \uin\n FILE_TYPE;
                  ITEM : \uin\n NUM;
                  FORE : \uin\n FIELD := DEFAULT_FORE;
                  AFT  : \uin\n FIELD := DEFAULT_AFT;
                  EXP  : \uin\n FIELD := DEFAULT_EXP);
    \uprocedure\n PUT(ITEM : \uin\n NUM;
                  FORE : \uin\n FIELD := DEFAULT_FORE;
                  AFT  : \uin\n FIELD := DEFAULT_AFT;
                  EXP  : \uin\n FIELD := DEFAULT_EXP);
          Outputs the value of the parameter ITEM as a decimal literal with
          the  format  defined  by  FORE,  AFT  and  EXP.   If the value is
          negative, a minus sign is included in the integer part.   If  EXP
          has  the  value  zero,  then the integer part to be output has as
          many digits as are needed to represent the integer  part  of  the
          value  of  ITEM, overriding FORE if necessary, or consists of the
          digit zero if the value of ITEM has no integer part.
          If EXP has a value greater than zero, then the integer part to be
          output has a single digit, which is nonzero except for the  value
          0.0 of ITEM.
          In  both  cases,  however,  if  the integer part to be output has
          fewer than  FORE  characters,  including  any  minus  sign,  then
          leading  spaces  are first output to make up the difference.  The
          number of digits of the fractional part is given by  AFT,  or  is
          one  if  AFT  equals  zero.   The  value  is rounded;  a value of
          exactly one half in the last place may be rounded  either  up  or
          down.
          If EXP has the value zero, there is no exponent part.  If EXP has
          a  value  greater  than zero, then the exponent part to be output
          has as many digits as are needed to represent the  exponent  part
          of  the  value  of ITEM (for which a single digit integer part is
          used), and includes an initial  sign (plus  or  minus).   If  the
          exponent  part  to  be  output  has  fewer  than  EXP characters,
          including the sign, then leading zeros  precede  the  digits,  to
          make  up the difference.  For the value 0.0 of ITEM, the exponent
          has the value zero.
    \uprocedure\n GET(FROM : \uin\n STRING; ITEM : \uout\n NUM; LAST : \uout\n POSITIVE);
          Reads a real value  from  the  beginning  of  the  given  string,
          following  the  same  rule as the GET procedure that reads a real
          value from a file, but treating the end of the string as  a  file
          terminator.   Returns,  in  the parameter ITEM, the value of type
          NUM that corresponds to the sequence input.  Returns in LAST  the
          index value such that FROM(LAST) is the last character read.
          The exception DATA_ERROR is raised if the sequence input does not
          have  the required syntax, or if the value obtained is not of the
          subtype NUM.
    \uprocedure\n PUT(TO   : \uout\n STRING;
                  ITEM : \uin\n NUM;
                  AFT  : \uin\n FIELD := DEFAULT_AFT;
                  EXP  : \uin\n INTEGER := DEFAULT_EXP);
          Outputs the value of the parameter  ITEM  to  the  given  string,
          following  the  same  rule as for output to a file, using a value
          for FORE such that the  sequence  of  characters  output  exactly
          fills the string, including any leading spaces.
\uExamples:\n
    \upackage\n REAL_IO \uis new\n FLOAT_IO(REAL); \uuse\n REAL_IO;
    -- default format used at instantiation, DEFAULT_EXP = 3
    X : REAL := -123.4567;  --  digits 8      (see 3.5.7)
    PUT(X); -- default format                   "-1.2345670E+02"
    PUT(X, FORE => 5, AFT => 3, EXP => 2);  --  "bbb-1.235E+2"
    PUT(X, 5, 3, 0);                        --  "b-123.457"
Note:
For  an item with a positive value, if output to a string exactly fills the
string without leading spaces, then output of  the  corresponding  negative
value will raise \vLAYOUT_ERROR\v1413..
:1417
14.3.9  \uInput-Output for Enumeration Types\n
The following procedures are defined in the generic \vpackage ENUMERATION_IO\v1418.,
which must be instantiated for the appropriate enumeration type  (indicated
by ENUM in the specification).
Values are output using either upper or lower case letters for identifiers.
This  is  specified  by the parameter SET, which is of the enumeration type
TYPE_SET.
    \utype\n TYPE_SET \uis\n (LOWER_CASE, UPPER_CASE);
The format (which includes any trailing spaces)  can  be  specified  by  an
optional  field  \vwidth\v1413.  parameter.  The default field width and letter case
are defined by the following variables that are  declared  in  the  generic
package ENUMERATION_IO:
    DEFAULT_WIDTH   : \vFIELD\v1413. := 0;
    DEFAULT_SETTING : TYPE_SET := UPPER_CASE;
The following procedures are provided:
    \vprocedure GET\v1413.(FILE : \uin\n \vFILE_TYPE\v1401.; ITEM : \uout\n ENUM);
    \uprocedure\n GET(ITEM : \uout\n ENUM);
          After  \vskipping\v1413.  any  leading  \vblanks\v1413.,  \vline terminators\v1413., or page
          terminators, reads an identifier according to the syntax of  this
          lexical   element   (lower   and   upper  case  being  considered
          equivalent), or a character literal according to  the  syntax  of
          this  lexical  element  (including the apostrophes).  Returns, in
          the parameter ITEM, the value of type ENUM  that  corresponds  to
          the sequence input.
          The exception \vDATA_ERROR\v1413. is raised if the sequence input does not
          have  the  required  syntax,  or  if  the identifier or character
          literal does not correspond to a value of the subtype ENUM.
    \vprocedure PUT\v1413.(FILE  : \uin\n FILE_TYPE;
                  ITEM  : \uin\n ENUM;
                  WIDTH : \uin\n FIELD := DEFAULT_WIDTH;
                  SET   : \uin\n TYPE_SET := DEFAULT_SETTING);
    \uprocedure\n PUT(ITEM  : \uin\n ENUM;
                  WIDTH : \uin\n FIELD := DEFAULT_WIDTH;
                  SET   : \uin\n TYPE_SET := DEFAULT_SETTING);
          Outputs the value of the parameter ITEM as an enumeration literal
          (either an identifier or  a  character  literal).   The  optional
          parameter  SET indicates whether lower case or upper case is used
          for identifiers;  it has no effect for  character  literals.   If
          the   sequence  of  characters  produced  has  fewer  than  WIDTH
          characters, then trailing spaces are finally output  to  make  up
          the difference.
    \uprocedure\n GET(FROM : \uin\n STRING; ITEM : \uout\n ENUM; LAST : \uout\n POSITIVE);
          Reads  an  enumeration  value  from  the  beginning  of the given
          string, following the same rule as the GET  procedure that  reads
          an  enumeration  value  from  a file, but treating the end of the
          string as a file terminator.  Returns, in the parameter ITEM, the
          value of type  ENUM  that  corresponds  to  the  sequence  input.
          Returns  in LAST the index value such that FROM(LAST) is the last
          character read.
          The exception DATA_ERROR is raised if the sequence input does not
          have the required syntax,  or  if  the  identifier  or  character
          literal does not correspond to a value of the subtype ENUM.
    \uprocedure\n PUT(TO   : \uout\n STRING;
                  ITEM : \uin\n ENUM;
                  SET  : \uin\n TYPE_SET := DEFAULT_SETTING);
          Outputs  the  value  of  the  parameter ITEM to the given string,
          following the same rule as for output to a file, using the length
          of the given string as the value for WIDTH.
Although the  specification  of  the  package  ENUMERATION_IO  would  allow
instantiation for an integer type, this is not the intended purpose of this
generic  package,  and  the effect of such instantiations is not defined by
the language.
\uNotes:\n
There  is  a  difference  between  PUT  defined  for  characters,  and  for
enumeration values.  Thus
    TEXT_IO.PUT('A');  --  outputs the character A
    package CHAR_IO is new TEXT_IO.ENUMERATION_IO(CHARACTER);
    CHAR_IO.PUT('A');  --  outputs the character 'A', between single quotes
The  type  BOOLEAN  is  an  enumeration  type,  hence ENUMERATION_IO can be
instantiated for this type.
:1418
14.3.10  \uSpecification of the Package Text_IO\n
    \uwith\n IO_EXCEPTIONS;
    \upackage\n TEXT_IO \uis\n
       \utype\n FILE_TYPE \uis limited private\n;
       \utype\n FILE_MODE \uis\n (IN_FILE, OUT_FILE);
       \utype\n COUNT \uis range\n 0 .. implementation defined;
       \usubtype\n POSITIVE_COUNT is COUNT \urange\n 1 .. COUNT'LAST;
       UNBOUNDED : \uconstant\n COUNT := 0; -- line and page length
       \usubtype\n FIELD       \uis\n INTEGER \urange\n 0 .. implementation defined;
       \usubtype\n NUMBER_BASE \uis\n INTEGER \urange\n 2 .. 16;
       \utype\n TYPE_SET \uis\n (LOWER_CASE, UPPER_CASE);
       -- File Management
       procedure CREATE (FILE : in out FILE_TYPE;
                         MODE : in FILE_MODE := OUT_FILE;
                         NAME : in STRING    := "";
                         FORM : in STRING    := "");
       procedure OPEN   (FILE : in out FILE_TYPE;
                         MODE : in FILE_MODE;
                         NAME : in STRING;
                         FORM : in STRING := "");
       procedure CLOSE  (FILE : in out FILE_TYPE);
       procedure DELETE (FILE : in out FILE_TYPE);
       procedure RESET  (FILE : in out FILE_TYPE; MODE : in FILE_MODE);
       procedure RESET  (FILE : in out FILE_TYPE);
       function  MODE   (FILE : in FILE_TYPE) return FILE_MODE;
       function  NAME   (FILE : in FILE_TYPE) return STRING;
       function  FORM   (FILE : in FILE_TYPE) return STRING;
       function  IS_OPEN(FILE : in FILE_TYPE) return BOOLEAN;
       -- Control of default input and output files
       procedure SET_INPUT (FILE : in FILE_TYPE);
       procedure SET_OUTPUT(FILE : in FILE_TYPE);
       function STANDARD_INPUT  return FILE_TYPE;
       function STANDARD_OUTPUT return FILE_TYPE;
       function CURRENT_INPUT   return FILE_TYPE;
       function CURRENT_OUTPUT  return FILE_TYPE;
       -- Specification of line and page lengths
       procedure SET_LINE_LENGTH(FILE : in FILE_TYPE; TO : in COUNT);
       procedure SET_LINE_LENGTH(TO : in COUNT);
       procedure SET_PAGE_LENGTH(FILE : in FILE_TYPE; TO : in COUNT);
       procedure SET_PAGE_LENGTH(TO : in COUNT);
       function  LINE_LENGTH(FILE : in FILE_TYPE) return COUNT;
       function  LINE_LENGTH return COUNT;
       function  PAGE_LENGTH(FILE : in FILE_TYPE) return COUNT;
       function  PAGE_LENGTH return COUNT;
       -- Column, Line, and Page Control
procedure NEW_LINE (FILE : in FILE_TYPE; SPACING : in POSITIVE_COUNT := 1);
procedure NEW_LINE (SPACING : in POSITIVE_COUNT := 1);
procedure SKIP_LINE (FILE : in FILE_TYPE; SPACING :in POSITIVE_COUNT := 1);
procedure SKIP_LINE  (SPACING : in POSITIVE_COUNT := 1);
       function  END_OF_LINE(FILE : in FILE_TYPE) return BOOLEAN;
       function  END_OF_LINE return BOOLEAN;
       procedure NEW_PAGE   (FILE : in FILE_TYPE);
       procedure NEW_PAGE;
       procedure SKIP_PAGE  (FILE : in FILE_TYPE);
       procedure SKIP_PAGE;
       function  END_OF_PAGE(FILE : in FILE_TYPE) return BOOLEAN;
       function  END_OF_PAGE return BOOLEAN;
       function  END_OF_FILE(FILE : in FILE_TYPE) return BOOLEAN;
       function  END_OF_FILE return BOOLEAN;
       procedure SET_COL (FILE : in FILE_TYPE; TO : in POSITIVE_COUNT);
       procedure SET_COL (TO   : in POSITIVE_COUNT);
       procedure SET_LINE(FILE : in FILE_TYPE; TO : in POSITIVE_COUNT);
       procedure SET_LINE(TO   : in POSITIVE_COUNT);
       function COL (FILE : in FILE_TYPE) return POSITIVE_COUNT;
       function COL  return POSITIVE_COUNT;
       function LINE(FILE : in FILE_TYPE) return POSITIVE_COUNT;
       function LINE return POSITIVE_COUNT;
       function PAGE(FILE : in FILE_TYPE) return POSITIVE_COUNT;
       function PAGE return POSITIVE_COUNT;
       -- Character Input-Output
       procedure GET(FILE : in  FILE_TYPE; ITEM : out CHARACTER);
       procedure GET(ITEM : out CHARACTER);
       procedure PUT(FILE : in  FILE_TYPE; ITEM : in CHARACTER);
       procedure PUT(ITEM : in  CHARACTER);
       -- String Input-Output
       procedure GET(FILE : in  FILE_TYPE; ITEM : out STRING);
       procedure GET(ITEM : out STRING);
       procedure PUT(FILE : in  FILE_TYPE; ITEM : in STRING);
       procedure PUT(ITEM : in  STRING);
       procedure GET_LINE(FILE : in  FILE_TYPE; ITEM : out STRING; LAST :
         out NATURAL);
       procedure GET_LINE(ITEM : out STRING; LAST : out NATURAL);
       procedure PUT_LINE(FILE : in  FILE_TYPE; ITEM : in STRING);
       procedure PUT_LINE(ITEM : in  STRING);
       -- Generic package for Input-Output of Integer Types
       generic
          type NUM is range <>;
       package INTEGER_IO is
          DEFAULT_WIDTH : FIELD := NUM'WIDTH;
          DEFAULT_BASE  : NUMBER_BASE := 10;
procedure GET(FILE : in  FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0);
          procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0);
          procedure PUT(FILE  : in FILE_TYPE;
                        ITEM  : in NUM;
                        WIDTH : in FIELD := DEFAULT_WIDTH;
                        BASE  : in NUMBER_BASE := DEFAULT_BASE);
          procedure PUT(ITEM  : in NUM;
                        WIDTH : in FIELD := DEFAULT_WIDTH;
                        BASE  : in NUMBER_BASE := DEFAULT_BASE);
     procedure GET(FROM : in  STRING; ITEM : out NUM; LAST : out POSITIVE);
     procedure PUT(TO   : out STRING;
                        ITEM : in NUM;
                        BASE : in NUMBER_BASE := DEFAULT_BASE);
     end INTEGER_IO;
       -- Generic packages for Input-Output of Real Types
       generic
          type NUM is digits <>;
       package FLOAT_IO is
          DEFAULT_FORE : FIELD := 2;
          DEFAULT_AFT  : FIELD := NUM'DIGITS-1;
          DEFAULT_EXP  : FIELD := 3;
 procedure GET(FILE : in FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0);
        procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0);
        procedure PUT(FILE : in FILE_TYPE;
                      ITEM : in NUM;
                      FORE : in FIELD := DEFAULT_FORE;
                      AFT  : in FIELD := DEFAULT_AFT;
                      EXP  : in FIELD := DEFAULT_EXP);
        procedure PUT(ITEM : in NUM;
                      FORE : in FIELD := DEFAULT_FORE;
                      AFT  : in FIELD := DEFAULT_AFT;
                      EXP  : in FIELD := DEFAULT_EXP);
      procedure GET(FROM : in STRING; ITEM : out NUM; LAST : out POSITIVE);
          procedure PUT(TO   : out STRING;
                        ITEM : in NUM;
                        AFT  : in FIELD := DEFAULT_AFT;
                        EXP  : in FIELD := DEFAULT_EXP);
       end FLOAT_IO;
       generic
          type NUM is delta <>;
       package FIXED_IO is
          DEFAULT_FORE : FIELD := NUM'FORE;
          DEFAULT_AFT  : FIELD := NUM'AFT;
          DEFAULT_EXP  : FIELD := 0;
 procedure GET(FILE : in FILE_TYPE; ITEM : out NUM; WIDTH : in FIELD := 0);
          procedure GET(ITEM : out NUM; WIDTH : in FIELD := 0);
          procedure PUT(FILE : in FILE_TYPE;
                        ITEM : in NUM;
                        FORE : in FIELD := DEFAULT_FORE;
                        AFT  : in FIELD := DEFAULT_AFT;
                        EXP  : in FIELD := DEFAULT_EXP);
          procedure PUT(ITEM : in NUM;
                        FORE : in FIELD := DEFAULT_FORE;
                        AFT  : in FIELD := DEFAULT_AFT;
                        EXP  : in FIELD := DEFAULT_EXP);
     procedure GET(FROM : in  STRING; ITEM : out NUM; LAST : out POSITIVE);
          procedure PUT(TO   : out STRING;
                        ITEM : in NUM;
                        AFT  : in FIELD := DEFAULT_AFT;
                        EXP  : in FIELD := DEFAULT_EXP);
       end FIXED_IO;
       -- Generic package for Input-Output of Enumeration Types
       generic
          type ENUM is (<>);
       package ENUMERATION_IO is
          DEFAULT_WIDTH   : FIELD := 0;
          DEFAULT_SETTING : TYPE_SET := UPPER_CASE;
          procedure GET(FILE  : in FILE_TYPE; ITEM : out ENUM);
          procedure GET(ITEM  : out ENUM);
          procedure PUT(FILE  : in FILE_TYPE;
                        ITEM  : in ENUM;
                        WIDTH : in FIELD    := DEFAULT_WIDTH;
                        SET   : in TYPE_SET := DEFAULT_SETTING);
          procedure PUT(ITEM  : in ENUM;
                        WIDTH : in FIELD    := DEFAULT_WIDTH;
                        SET   : in TYPE_SET := DEFAULT_SETTING);
    procedure GET(FROM : in  STRING; ITEM : out ENUM; LAST : out POSITIVE);
          procedure PUT(TO   : out STRING;
                        ITEM : in  ENUM;
                        SET  : in  TYPE_SET := DEFAULT_SETTING);
       end ENUMERATION_IO;
    -- Exceptions
       STATUS_ERROR : \uexception renames\n IO_EXCEPTIONS.STATUS_ERROR;
       MODE_ERROR   : \uexception renames\n IO_EXCEPTIONS.MODE_ERROR;
       NAME_ERROR   : \uexception renames\n IO_EXCEPTIONS.NAME_ERROR;
       USE_ERROR    : \uexception renames\n IO_EXCEPTIONS.USE_ERROR;
       DEVICE_ERROR : \uexception renames\n IO_EXCEPTIONS.DEVICE_ERROR;
       END_ERROR    : \uexception renames\n IO_EXCEPTIONS.END_ERROR;
       DATA_ERROR   : \uexception renames\n IO_EXCEPTIONS.DATA_ERROR;
       LAYOUT_ERROR : \uexception renames\n IO_EXCEPTIONS.LAYOUT_ERROR;
    \uprivate\n
       -- implementation-dependent
    \uend\n TEXT_IO;
:1419
14.4  \uExceptions in Input-Output\n
The following exceptions can be raised by  input-output  operations.   They
are  declared  in the \vpackage IO_EXCEPTIONS\v1420., defined in section 14.5;  this
package is named in the context clause for each of the  three  input-output
packages.   Only  outline  descriptions  are  given of the conditions under
which NAME_ERROR, USE_ERROR, and DEVICE_ERROR are raised;  for full details
see Appendix F.  If more than one error condition exists, the corresponding
exception that appears earliest in the following list is the  one  that  is
raised.
The  exception  STATUS_ERROR is raised by an attempt to operate upon a \vfile\v1401.
that is not open, and by an attempt to open a file that is already open.
The exception MODE_ERROR is raised by an attempt to read from, or test  for
the  end  of, a file whose current mode is \vOUT_FILE\v1401., and also by an attempt
to write to a file whose current mode is \vIN_FILE\v1401..  In the case of  TEXT_IO,
the  exception MODE_ERROR is also raised by specifying a file whose current
mode is OUT_FILE in a call of \vSET_INPUT\v1410., \vSKIP_LINE\v1412., \vEND_OF_LINE\v1412., \vSKIP_PAGE\v1412.,
or \vEND_OF_PAGE\v1412.;  and by specifying a file whose current mode is IN_FILE  in
a   call  of  \vSET_OUTPUT\v1410.,  \vSET_LINE_LENGTH\v1411.,  \vSET_PAGE_LENGTH\v1411.,  \vLINE_LENGTH\v1412.,
\vPAGE_LENGTH\v1412., \vNEW_LINE\v1412., or \vNEW_PAGE\v1412..
The exception NAME_ERROR is raised by a call  of  CREATE  or  \vOPEN\v1403.  if  the
string given for the parameter \vNAME\v1401. does not allow the identification of an
\vexternal  file\v1401..   For  example,  this  exception is raised if the string is
improper, or, alternatively, if either none or more than one external  file
corresponds to the string.
The  exception USE_ERROR is raised if an operation is attempted that is not
possible for reasons that depend on characteristics of the  external  file.
For  example, this exception is raised by the \vprocedure CREATE\v1403., among other
circumstances, if the given mode is OUT_FILE  but  the  form  specifies  an
input  only  device, if the parameter FORM specifies invalid access rights,
or if an external file with the given name already exists  and  overwriting
is not allowed.
The exception DEVICE_ERROR is raised if an input-output operation cannot be
completed because of a malfunction of the underlying system.
The exception END_ERROR is raised by an attempt to skip (read past) the end
of a file.
The exception DATA_ERROR may be raised by the \vprocedure READ\v1404. if the element
read cannot be interpreted as a value of the required type.  This exception
is  also  raised by a \vprocedure GET\v1413. (defined in the \vpackage TEXT_IO\v1408.) if the
input character sequence fails to satisfy the required syntax,  or  if  the
value  input  does not belong to the range of the required type or subtype.
The exception LAYOUT_ERROR is raised (in text input-output) by  \vCOL\v1412.,  \vLINE\v1412.,
or   \vPAGE\v1412.   if  the  value  returned  exceeds  COUNT'LAST.   The  exception
LAYOUT_ERROR is also raised on output by an attempt to set column  or  line
numbers  in  excess of specified maximum line or page lengths, respectively
(excluding the unbounded cases).  It is also raised by an attempt   to  \vPUT\v1413.
too many characters to a string.
:1420
14.5  \uSpecification of the Package IO_Exceptions\n
This  package  defines the exceptions needed by the packages SEQUENTIAL_IO,
DIRECT_IO, and TEXT_IO.
    \upackage\n IO_EXCEPTIONS \uis\n
       STATUS_ERROR : \uexception\n;
       MODE_ERROR   : \uexception\n;
       NAME_ERROR   : \uexception\n;
       USE_ERROR    : \uexception\n;
       DEVICE_ERROR : \uexception\n;
       END_ERROR    : \uexception\n;
       DATA_ERROR   : \uexception\n;
       LAYOUT_ERROR : \uexception\n;
    \uend\n IO_EXCEPTIONS;
:1421
14.6  \uLow Level Input-Output\n
A low level input-output operation is an operation  acting  on  a  physical
device.   Such  an  operation  is  handled by using one of the (overloaded)
predefined procedures SEND_CONTROL and RECEIVE_CONTROL.
A procedure SEND_CONTROL may be used  to  send  control  information  to  a
physical  device.   A  procedure RECEIVE_CONTROL may be used to monitor the
execution of an input-output operation by requesting information  from  the
physical device.
Such  procedures are declared in the standard package LOW_LEVEL_IO and have
two parameters identifying the device and the data.  However, the kinds and
formats  of  the  control  information  will   depend   on   the   physical
characteristics  of  the  machine  and the device.  Hence, the types of the
parameters are implementation-defined.   Overloaded  definitions  of  these
procedures should be provided for the supported devices.
The  visible  part  of the package defining these procedures is outlined as
follows:
 \upackage\n LOW_LEVEL_IO \uis\n
    --  declarations of the possible types for DEVICE and DATA;
    --  declarations of overloaded procedures for these types:
 \uprocedure\n SEND_CONTROL    (DEVICE : device_type; DATA : \uin out\n data_type);
 \uprocedure\n RECEIVE_CONTROL (DEVICE : device_type; DATA : \uin out\n data_type);
 end;
The bodies of the procedures SEND_CONTROL and RECEIVE_CONTROL  for  various
devices  can  be  supplied  in the body of the package LOW_LEVEL_IO.  These
procedure bodies may be written with code statements.
:1422
14.7  \uExample of Input-Output\n
The following example shows the  use  of  some  of  the  text  input-output
facilities  in  a dialogue with a user at a terminal.  The user is prompted
to type a color, and the program responds by giving the number of items  of
that  color  available  in  stock,  according to an inventory.  The default
input and output  files  are  used.   For  simplicity,  all  the  requisite
instantiations  are  given  within one subprogram;  in practice, a package,
separate from the procedure, would be used.
  \uwith\n TEXT_IO; \uuse\n TEXT_IO;
  \uprocedure\n DIALOGUE \uis\n
     \utype\n COLOR \uis\n (WHITE, RED, ORANGE, YELLOW, GREEN, BLUE, BROWN);
     \upackage\n COLOR_IO \uis new\n ENUMERATION_IO(ENUM => COLOR);
     \upackage\n NUMBER_IO \uis new\n INTEGER_IO(INTEGER);
     \uuse\n COLOR_IO, NUMBER_IO;
     INVENTORY : \uarray\n (COLOR) \uof\n INTEGER := (20, 17, 43, 10, 28, 173, 87);
     CHOICE : COLOR;
     \uprocedure\n ENTER_COLOR (SELECTION : \uout\n COLOR) \uis\n
     \ubegin\n
        \uloop\n
           \ubegin\n
              PUT("Color selected: ");  --  prompts user
              GET(SELECTION);  --  accepts color typed, or raises exception
              \ureturn\n;
           \uexception\n
              \uwhen\n DATA_ERROR =>
                 PUT("Invalid color, try again.  ");  --  user has typed
                 NEW_LINE(2);                         --   new line
                 --  completes execution of the block statement
           \uend\n;
        \uend loop\n;  --  repeats the block statement until color accepted
     \uend\n;
  \ubegin\n --  statements of DIALOGUE;
     NUMBER_IO.DEFAULT_WIDTH := 5;
     \uloop\n
        ENTER_COLOR(CHOICE);  --  user types color and new line
        SET_COL(5);  PUT(CHOICE); PUT(" items available:");
        SET_COL(40); PUT(INVENTORY(CHOICE));  --  default width is 5
        NEW_LINE;
     \uend loop\n;
  \uend\n DIALOGUE;
Example of an interaction (characters typed by the user are italicized):
    Color selected:  \uBlack\n
    Invalid color, try again.
    Color selected:  \uBlue\n
        BLUE items available:         173
    Color selected:  \uYellow\n
        YELLOW items available:        10
:1500
A.      \uPredefined Language Attributes\n
This  annex  summarizes  the  definitions given elsewhere of the predefined
language attributes.
P'ADDRESS         For a prefix P that denotes an object, a program unit,  a
                  label, or an entry:
                  Yields  the  address  of  the  first of the storage units
                  allocated to P.  For a subprogram, package, task unit, or
                  label, this value refers to the machine  code  associated
                  with  the  corresponding body or statement.  For an entry
                  for which an address clause has  been  given,  the  value
                  refers  to  the  corresponding  hardware  interrupt.  The
                  value of this attribute is of the type ADDRESS defined in
                  the package SYSTEM.  (See 13.7.2.)
P'AFT             For a prefix P that denotes a fixed point subtype:
                  Yields the number of  decimal  digits  needed  after  the
                  point  to  accommodate  the  precision  of the subtype P,
                  unless the delta of the subtype P is greater than 0.1, in
                  which case the attribute yields the value one.  (P'AFT is
                  the smallest positive integer N for which (10**N)*P'DELTA
                  is greater than or equal to  one.)   The  value  of  this
                  attribute   is   of  the  type  universal_integer.   (See
                  3.5.10.)
P'BASE            For a prefix P that denotes a type or subtype:
                  This attribute denotes the base type of P.   It  is  only
                  allowed  as  the prefix of the name of another attribute:
                  for example, P'BASE'FIRST.  (See 3.3.3.)
P'CALLABLE        For a prefix P that is appropriate for a task type:
                  Yields the value FALSE when the execution of the  task  P
                  is  either  completed  or terminated, or when the task is
                  abnormal;  yields the value TRUE otherwise.  The value of
                  this attribute is of the predefined type  BOOLEAN.   (See
                  9.9.)
P'CONSTRAINED     For a prefix P that denotes an  object  of  a  type  with
                  discriminants:
                  Yields  the  value  TRUE  if  a  discriminant  constraint
                  applies to the object P, or if the object is  a  constant
                  (including a formal parameter or generic formal parameter
                  of  mode in);  yields the value FALSE otherwise.  If P is
                  a generic formal parameter of mode in out, or if P  is  a
                  formal  parameter of mode in out or out and the type mark
                  given  in  the  corresponding   parameter   specification
                  denotes  an  unconstrained  type with discriminants, then
                  the value of this attribute is obtained from that of  the
                  corresponding   actual  parameter.   The  value  of  this
                  attribute  is  of  the  predefined  type  BOOLEAN.   (See
                  3.7.4.)
P'CONSTRAINED     For a prefix P that denotes a private type or subtype:
                  Yields  the  value  FALSE  if  P denotes an unconstrained
                  nonformal private type with discriminants;   also  yields
                  the  value  FALSE  if  P denotes a generic formal private
                  type and the  associated  actual  subtype  is  either  an
                  unconstrained type with discriminants or an unconstrained
                  array  type;  yields the value TRUE otherwise.  The value
                  of this attribute is  of  the  predefined  type  BOOLEAN.
                  (See 7.4.2.)
P'COUNT           For a prefix P that denotes an entry of a task unit:
                  Yields  the number of entry calls presently queued on the
                  entry (if the attribute is  evaluated  within  an  accept
                  statement for the entry P, the count does not include the
                  calling  task).   The  value  of this attribute is of the
                  type universal_integer.  (See 9.9.)
P'DELTA           For a prefix P that denotes a fixed point  subtype:
                  Yields the value of the  delta  specified  in  the  fixed
                  accuracy definition for the subtype P.  The value of this
                  attribute  is  of the type universal_real.  (See 3.5.10.)
P'DIGITS          For a prefix P that denotes a floating point subtype:
                  Yields the  number  of  decimal  digits  in  the  decimal
                  mantissa  of  model  numbers  of  the  subtype  P.  (This
                  attribute yields the number D  of  section  3.5.7.)   The
                  value of this attribute is of the type universal_integer.
                  (See 3.5.8.)
P'EMAX            For a prefix P that denotes a floating point  subtype:
                  Yields the largest exponent value in the binary canonical
                  form  of model numbers of the subtype P.  (This attribute
                  yields the product 4*B of section 3.5.7.)  The  value  of
                  this  attribute  is  of the type universal_integer.  (See
                  3.5.8.)
P'EPSILON         For a prefix P that denotes a floating point subtype:
                  Yields the absolute value of the difference  between  the
                  model number 1.0 and the next model number above, for the
                  subtype  P.   The  value of this attribute is of the type
                  universal_real.  (See 3.5.8.)
P'FIRST           For a prefix P that denotes a scalar type, or  a  subtype
                  of a scalar type:
                  Yields the lower bound of P.  The value of this attribute
                  has the same type as P.  (See 3.5.)
P'FIRST           For a prefix P that is appropriate for an array type,  or
                  that denotes a constrained array subtype:
                  Yields  the  lower  bound  of the first index range.  The
                  value of this attribute has the same type as  this  lower
                  bound.  (See 3.6.2 and 3.8.2.)
P'FIRST(N)        For a prefix P that is appropriate for an array type,  or
                  that denotes a constrained array subtype:
                  Yields  the  lower  bound  of  the N-th index range.  The
                  value of this attribute has the same type as  this  lower
                  bound.   The  argument  N  must be a static expression of
                  type universal_integer.  The value of N must be  positive
                  (nonzero)  and  no greater than the dimensionality of the
                  array.  (See 3.6.2 and 3.8.2.)
P'FIRST_BIT       For a prefix P that  denotes  a  component  of  a  record
                  object:
                  Yields  the  offset,  from  the start of the first of the
                  storage units occupied by the component, of the first bit
                  occupied by the component.  This offset  is  measured  in
                  bits.   The  value  of  this  attribute  is  of  the type
                  universal_integer.  (See 13.7.2.)
P'FORE            For a prefix P that denotes a fixed point subtype:
                  Yields the minimum number of characters  needed  for  the
                  integer  part  of the decimal representation of any value
                  of the subtype P, assuming that the  representation  does
                  not  include  an  exponent,  but includes a one-character
                  prefix that is either a minus sign  or  a  space.   (This
                  minimum  number  does  not  include  superfluous zeros or
                  underlines, and is at least  two.)   The  value  of  this
                  attribute   is   of  the  type  universal_integer.   (See
                  3.5.10.)
P'IMAGE           For a prefix P that denotes a discrete type  or  subtype:
                  This  attribute  is  a  function with a single parameter.
                  The actual parameter X must be a value of the  base  type
                  of  P.   The  result  type is the predefined type STRING.
                  The result is the image of the value of  X,  that  is,  a
                  sequence  of characters representing the value in display
                  form.  The image of an integer value is the corresponding
                  decimal  literal;   without  underlines,  leading  zeros,
                  exponent,  or  trailing spaces;  but with a one character
                  prefix that is either a minus sign or a space.
                  The  image  of  an  enumeration  value  is   either   the
                  corresponding   identifier   in   upper   case   or   the
                  corresponding  character  literal  (including   the   two
                  apostrophes);   neither  leading  nor trailing spaces are
                  included.  The image of a character other than a  graphic
                  character is implementation-defined.  (See 3.5.5.)
P'LARGE           For a prefix P that denotes a real subtype:
                  The attribute yields the largest positive model number of
                  the  subtype  P.   The  value of this attribute is of the
                  type universal_real.  (See 3.5.8 and 3.5.10.)
P'LAST            For a prefix P that denotes a scalar type, or  a  subtype
                  of a scalar type:
                  Yields the upper bound of P.  The value of this attribute
                  has the same type as P.  (See 3.5.)
P'LAST            For a prefix P that is appropriate for an array type,  or
                  that denotes a constrained array subtype:
                  Yields  the  upper  bound  of the first index range.  The
                  value of this attribute has the same type as  this  upper
                  bound.  (See 3.6.2 and 3.8.2.)
P'LAST(N)         For a prefix P that  is  appropriate  for  an array type,
                  or that denotes a constrained array subtype:
                  Yields  the  upper  bound  of  the N-th index range.  The
                  value of this attribute has the same type as  this  upper
                  bound.   The  argument  N  must be a static expression of
                  type universal_integer.  The value of N must be  positive
                  (nonzero)  and  no greater than the dimensionality of the
                  array.  (See 3.6.2 and 3.8.2.)
P'LAST_BIT        For  a  prefix  P  that  denotes a component of a  record
                  object:
                  Yields  the  offset,  from the start of the first of  the
                  storage units occupied by the component, of the last  bit
                  occupied by the component.  This  offset  is  measured in
                  bits.   The  value  of  this  attribute  is  of  the type
                  universal_integer.  (See 13.7.2.)
P'LENGTH          For a prefix P that  is  appropriate  for  an array type,
                  or  that denotes a constrained array subtype:
                  Yields the number of values of the first index range
                  (zero  for  a  null  range).   The  value  of   this
                  attribute  is  of  the type universal_integer.  (See
                  3.6.2.)
P'LENGTH(N)            For a prefix P that  is  appropriate  for  an  array
                       type,  or  that denotes a constrained array subtype:
                       Yields the number of values of the N-th index  range
                       (zero   for  a  null  range).   The  value  of  this
                       attribute is of  the  type  universal_integer.   The
                       argument  N  must  be  a  static  expression of type
                       universal_integer.  The value of N must be  positive
                       (nonzero)  and no greater than the dimensionality of
                       the array.  (See 3.6.2 and 3.8.2.)
P'MACHINE_EMAX         For a prefix P that denotes a floating point type or
                       subtype:
                       Yields the largest value of exponent for the machine
                       representation of the base type of P.  The value  of
                       this  attribute  is  of  the type universal_integer.
                       (See 13.7.3.)
P'MACHINE_EMIN         For a prefix P that denotes a floating point type or
                       subtype:
                       Yields  the  smallest  (most  negative)   value   of
                       exponent  for the machine representation of the base
                       type of P.  The value of this attribute  is  of  the
                       type universal_integer.  (See 13.7.3.)
P'MACHINE_MANTISSA     For a prefix P that denotes a floating point type or
                       subtype:
                       Yields  the number of digits in the mantissa for the
                       machine representation of the base type  of  P  (the
                       digits  are  extended  digits  in  the  range  0  to
                       P'MACHINE_RADIX - 1).  The value of  this  attribute
                       is of the type universal_integer.  (See 13.7.3.)
P'MACHINE_OVERFLOWS    For a prefix P that denotes a real type or  subtype:
                       Yields  the value TRUE if every predefined operation
                       on values of the base type of P  either  provides  a
                       correct    result,    or    raises   the   exception
                       NUMERIC_ERROR in overflow  situations;   yields  the
                       value  FALSE otherwise.  The value of this attribute
                       is of the predefined type BOOLEAN.  (See 13.7.3.)
P'MACHINE_RADIX        For a prefix P that denotes a floating point type or
                       subtype:
                       Yields the value of the radix used  by  the  machine
                       representation  of the base type of P.  The value of
                       this attribute is  of  the  type  universal_integer.
                       (See 13.7.3.)
P'MACHINE_ROUNDS       For a prefix P that denotes a real type or  subtype:
                       Yields the value TRUE if every predefined arithmetic
                       operation  on  values  of  the base type of P either
                       returns  an  exact  result  or  performs   rounding;
                       yields the value FALSE otherwise.  The value of this
                       attribute  is  of the predefined type BOOLEAN.  (See
                       13.7.3.)
P'MANTISSA             For a prefix P that denotes a real subtype:
                       Yields the number of binary  digits  in  the  binary
                       mantissa  of  model numbers of the subtype P.  (This
                       attribute yields the number B of section 3.5.7 for a
                       floating point type, or of section 3.5.9 for a fixed
                       point type.)  The value of this attribute is of  the
                       type universal_integer.  (See 3.5.8 and 3.5.10.)
P'POS                  For a prefix P  that  denotes  a  discrete  type  or
                       subtype:
                       This   attribute   is   a  function  with  a  single
                       parameter.  The actual parameter X must be  a  value
                       of  the base type of P.  The result type is the type
                       universal_integer.   The  result  is  the   position
                       number  of  the value of the actual parameter.  (See
                       3.5.5.)
P'POSITION             For a prefix P that denotes a component of a  record
                       object:
                       Yields  the  offset,  from  the  start  of the first
                       storage unit occupied by the record, of the first of
                       the storage units occupied by the  component.   This
                       offset  is  measured in storage units.  The value of
                       this attribute is  of  the  type  universal_integer.
                       (See 13.7.2.)
P'PRED                 For a prefix P  that  denotes  a  discrete  type  or
                       subtype:
                       This   attribute   is   a  function  with  a  single
                       parameter.  The actual parameter X must be  a  value
                       of  the base type of P.  The result type is the base
                       type of P.  The result is the value  whose  position
                       number  is  one  less than that of X.  The exception
                       CONSTRAINT_ERROR is raised if X equals P'BASE'FIRST.
                       (See 3.5.5.)
P'RANGE                For a prefix P that  is  appropriate  for  an  array
                       type,  or  that denotes a constrained array subtype:
                       Yields the first index range  of  P,  that  is,  the
                       range P'FIRST .. P'LAST.  (See 3.6.2.)
P'RANGE(N)             For a prefix P that  is  appropriate  for  an  array
                       type,  or  that denotes a constrained array subtype:
                       Yields the N-th index range of P, that is, the range
                       P'FIRST(N) .. P'LAST(N).  (See 3.6.2.)
P'SAFE_EMAX            For a prefix P that denotes a floating point type or
                       subtype:
                       Yields the largest  exponent  value  in  the  binary
                       canonical  form  of safe numbers of the base type of
                       P.  (This attribute yields the number E  of  section
                       3.5.7.)   The value of this attribute is of the type
                       universal_integer.  (See 3.5.8.)
P'SAFE_LARGE           For a prefix P that denotes a real type or  subtype:
                       Yields  the largest positive safe number of the base
                       type of P.  The value of this attribute  is  of  the
                       type universal_real.  (See 3.5.8 and 3.5.10.)
P'SAFE_SMALL           For a prefix P that denotes a real type or  subtype:
                       Yields  the  smallest positive (nonzero) safe number
                       of the base type of P.  The value of this  attribute
                       is  of  the  type  universal_real.   (See  3.5.8 and
                       3.5.10.)
P'SIZE                 For a prefix P that denotes an object:
                       Yields the number of  bits  allocated  to  hold  the
                       object.   The value of this attribute is of the type
                       universal_integer.  (See 13.7.2.)
P'SIZE                 For a prefix P that denotes any type or subtype:
                       Yields the minimum number of bits that is needed  by
                       the  implementation  to  hold any possible object of
                       the type or subtype P.  The value of this  attribute
                       is of the type universal_integer.  (See 13.7.2.)
P'SMALL                For a prefix P that denotes a real  subtype:
                       Yields  the smallest positive (nonzero) model number
                       of the subtype P.  The value of this attribute is of
                       the type universal_real.  (See 3.5.8 and 3.5.10.)
P'STORAGE_SIZE         For a prefix  P  that  denotes  an  access  type  or
                       subtype:
                       Yields  the  total  number of storage units reserved
                       for the collection associated with the base type  of
                       P.   The  value  of  this  attribute  is of the type
                       universal_integer.  (See 13.7.2.)
P'STORAGE_SIZE         For a prefix P that denotes a task type  or  a  task
                       object:
                       Yields the number of storage units reserved for each
                       activation  of  a  task  of  the  type  P or for the
                       activation of the task object P.  The value of  this
                       attribute  is  of  the type universal_integer.  (See
                       13.7.2.)
P'SUCC                 For a prefix P  that  denotes  a  discrete  type  or
                       subtype:
                       This   attribute   is   a  function  with  a  single
                       parameter.  The actual parameter X must be  a  value
                       of  the base type of P.  The result type is the base
                       type of P.  The result is the value  whose  position
                       number    is  one  greater  than  that  of  X.   The
                       exception CONSTRAINT_ERROR is  raised  if  X  equals
                       P'BASE'LAST.  (See 3.5.5.)
P'TERMINATED           For a prefix P that is appropriate for a task  type:
                       Yields  the  value TRUE if the task P is terminated;
                       yields the value FALSE otherwise.  The value of this
                       attribute is of the predefined type  BOOLEAN.   (See
                       9.9.)
P'VAL                  For a prefix P  that  denotes  a  discrete  type  or
                       subtype:
                       This  attribute  is a special function with a single
                       parameter X which can be of any integer  type.   The
                       result  type  is  the base type of P.  The result is
                       the   value   whose   position   number    is    the
                       universal_integer  value  corresponding  to  X.  The
                       exception  CONSTRAINT_ERROR   is   raised   if   the
                       universal_integer value corresponding to X is not in
                       the range P'POS(P'BASE'FIRST) .. P'POS(P'BASE'LAST).
                       (See 3.5.5.)
P'VALUE                For a prefix P  that  denotes  a  discrete  type  or
                       subtype:
                       This   attribute   is   a  function  with  a  single
                       parameter.  The actual parameter X must be  a  value
                       of  the  predefined type STRING.  The result type is
                       the base type of P.  Any leading  and  any  trailing
                       spaces   of   the   sequence   of   characters  that
                       corresponds to X  are ignored.
                       For  an  enumeration  type,  if  the   sequence   of
                       characters  has the syntax of an enumeration literal
                       and if this literal exists for the base type  of  P,
                       the  result  is the corresponding enumeration value.
                       For an integer type, if the sequence  of  characters
                       has  the  syntax  of  an  integer  literal,  with an
                       optional single leading character that is a plus  or
                       minus sign, and if there is a corresponding value in
                       the  base  type  of P, the result is this value.  In
                       any other case, the  exception  CONSTRAINT_ERROR  is
                       raised.  (See 3.5.5.)
P'WIDTH                For a prefix P that denotes a discrete  subtype:
                       Yields  the  maximum image length over all values of
                       the  subtype  P  (the  image  is  the  sequence   of
                       characters  returned  by  the attribute IMAGE).  The
                       value   of   this   attribute   is   of   the   type
                       universal_integer.  (See 3.5.5.)
:1600
B.      \uPredefined Language Pragmas\n
This annex defines the pragmas LIST, PAGE, and OPTIMIZE, and summarizes the
definitions given elsewhere of the remaining language-defined pragmas.
Pragma                                   Meaning
CONTROLLED     Takes the simple name  of  an  access  type  as  the  single
               argument.   This  pragma  is only allowed immediately within
               the declarative part or package specification that  contains
               the  declaration  of  the access type;  the declaration must
               occur before the pragma.  This pragma is not allowed  for  a
               derived  type.  This pragma specifies that automatic storage
               reclamation must not be performed for objects designated  by
               values of the access type, except upon leaving the innermost
               block statement, subprogram body, or task body that encloses
               the  access  type  declaration,  or  after  leaving the main
               program (see 4.8).
ELABORATE      Takes one or more simple names  denoting  library  units  as
               arguments.   This  pragma  is only allowed immediately after
               the  context  clause  of  a  compilation  unit  (before  the
               subsequent  library  unit or secondary unit).  Each argument
               must be the simple name of a library unit mentioned  by  the
               context    clause.    This   pragma   specifies   that   the
               corresponding library unit body must  be  elaborated  before
               the  given  compilation unit.  If the given compilation unit
               is a subunit, the  library  unit  body  must  be  elaborated
               before  the body of the ancestor library unit of the subunit
               (see 10.5).
INLINE         Takes one or more names as arguments;  each name  is  either
               the   name  of  a  subprogram  or  the  name  of  a  generic
               subprogram.  This pragma is only allowed at the place  of  a
               declarative   item   in   a   declarative  part  or  package
               specification, or after a library unit in a compilation, but
               before  any  subsequent  compilation  unit.    This   pragma
               specifies  that  the  subprogram  bodies  should be expanded
               inline at each call  whenever possible;  in the  case  of  a
               generic  subprogram,  the  pragma  applies  to  calls of its
               instantiations (see 6.3.2).
INTERFACE      Takes a language name and a subprogram  name  as  arguments.
               This  pragma  is allowed at the place of a declarative item,
               and must apply in this case to a subprogram declared  by  an
               earlier  declarative  item  of  the same declarative part or
               package specification.  This pragma is also  allowed  for  a
               library unit;  in this case the pragma must appear after the
               subprogram    declaration,   and   before   any   subsequent
               compilation unit.  This pragma specifies the other  language
               (and  thereby  the  calling  conventions)  and  informs  the
               compiler that an object module  will  be  supplied  for  the
               corresponding subprogram (see 13.9).
LIST           Takes one of  the  identifiers  ON  or  OFF  as  the  single
               argument.   This  pragma  is  allowed  anywhere  a pragma is
               allowed.  It specifies that listing of the compilation is to
               be continued or suspended  until  a  LIST  pragma  with  the
               opposite argument is given within the same compilation.  The
               pragma  itself is always listed if the compiler is producing
               a listing.
MEMORY_SIZE    Takes a numeric literal as the single argument.  This pragma
               is only allowed at the start of a  compilation,  before  the
               first  compilation  unit  (if  any) of the compilation.  The
               effect of this pragma is to use the value of  the  specified
               numeric  literal  for  the  definition  of  the named number
               MEMORY_SIZE (see 13.7).
OPTIMIZE       Takes one of the identifiers TIME or  SPACE  as  the  single
               argument.   This pragma is only allowed within a declarative
               part and it applies to  the  block  or  body  enclosing  the
               declarative part.  It specifies whether time or space is the
               primary optimization criterion.
PACK           Takes the simple name of a  record  or  array  type  as  the
               single  argument. The allowed positions for this pragma, and
               the restrictions on the named type, are governed by the same
               rules as for a representation clause. The  pragma  specifies
               that  storage minimization should be the main criterion when
               selecting the representation of the given type  (see  13.1).
PAGE           This pragma has no  argument,  and  is  allowed  anywhere  a
               pragma is allowed.  It specifies that the program text which
               follows  the  pragma  should  start  on  a  new page (if the
               compiler is currently producing a listing).
PRIORITY       Takes a static expression of the predefined integer  subtype
               PRIORITY  as  the  single  argument.   This  pragma  is only
               allowed  within  the  specification  of  a  task   unit   or
               immediately  within the outermost declarative part of a main
               program.  It specifies the priority of the task (or tasks of
               the task type) or the priority  of  the  main  program  (see
               9.8).
SHARED         Takes the simple name of a variable as the single  argument.
               This  pragma  is  allowed only for a variable declared by an
               object declaration and whose type  is  a  scalar  or  access
               type;   the  variable  declaration  and the pragma must both
               occur  (in  this  order)   immediately   within   the   same
               declarative  part  or  package  specification.   This pragma
               specifies that every read or update of  the  variable  is  a
               synchronization  point for that variable.  An implementation
               must restrict the objects for which this pragma  is  allowed
               to  objects  for  which  each  of  direct reading and direct
               updating is implemented as  an  indivisible  operation  (see
               9.11).
STORAGE_UNIT   Takes a numeric literal as the single argument.  This pragma
               is  only  allowed  at the start of a compilation, before the
               first compilation unit (if any)  of  the  compilation.   The
               effect  of  this pragma is to use the value of the specified
               numeric literal for  the  definition  of  the  named  number
               STORAGE_UNIT (see 13.7).
SUPPRESS       Takes as arguments the identifier of a check and  optionally
               also  the  name  of  either  an object, a type or subtype, a
               subprogram, a task unit, or a generic unit.  This pragma  is
               only allowed either immediately within a declarative part or
               immediately  within  a package specification.  In the latter
               case, the only allowed form is with a name that  denotes  an
               entity   (or   several   overloaded   subprograms)  declared
               immediately   within   the   package   specification.    The
               permission to omit the given check extends from the place of
               the  pragma  to the end of the declarative region associated
               with the innermost  enclosing  block  statement  or  program
               unit.   For  a  pragma given in a package specification, the
               permission extends to the end of  the  scope  of  the  named
               entity.
               If  the  pragma  includes a name, the permission to omit the
               given check is further restricted:  it  is  given  only  for
               operations on the named object or on all objects of the base
               type  of  a  named  type  or  subtype;  for calls of a named
               subprogram;  for activations of  tasks  of  the  named  task
               type;   or for instantiations of the given generic unit (see
               11.7).
SYSTEM_NAME    Takes an enumeration literal as the  single  argument.  This
               pragma is only allowed at the start of a compilation, before
               the first compilation unit (if any) of the compilation.  The
               effect of this pragma is to use the enumeration literal with
               the  specified identifier for the definition of the constant
               SYSTEM_NAME.  This pragma is only allowed if  the  specified
               identifier  corresponds  to  one of the literals of the type
               NAME declared in the package SYSTEM (see 13.7).
:1700
C.      \uPredefined Language Environment\n
This  annex  outlines  the specification of the package STANDARD containing
all predefined identifiers in the language.  The corresponding package body
is implementation-defined and is not shown.
The operators that are predefined for the types  declared  in  the  package
STANDARD are given in comments since they are implicitly declared.  Italics
are  used for  pseudo-names of anonymous types (such as universal_real) and
for   undefined   information   (such   as    implementation_defined    and
any_fixed_point_type).
package STANDARD is
   type BOOLEAN is (FALSE, TRUE);
   -- The predefined relational operators for this type are as follows:
   -- function "="   (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "/="  (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "<"   (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "<="  (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function ">"   (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function ">="  (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- The predefined logical operators and the predefined logical  negation
      operator are as follows:
   -- function "and" (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "or"  (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "xor" (LEFT, RIGHT : BOOLEAN) return BOOLEAN;
   -- function "not" (RIGHT : BOOLEAN) return BOOLEAN;
   -- The universal type universal_integer is predefined.
   type INTEGER is implementation_defined;
   -- The predefined operators for this type are as follows:
   -- function "="  (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function "/=" (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function "<"  (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function "<=" (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function ">"  (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function ">=" (LEFT, RIGHT : INTEGER) return BOOLEAN;
   -- function "+"   (RIGHT : INTEGER) return INTEGER;
   -- function "-"   (RIGHT : INTEGER) return INTEGER;
   -- function "\uabs\n" (RIGHT : INTEGER) return INTEGER;
   -- function "+"   (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "-"   (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "*"   (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "/"   (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "rem" (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "mod" (LEFT, RIGHT : INTEGER) return INTEGER;
   -- function "**"  (LEFT : INTEGER; RIGHT : INTEGER) return INTEGER;
   -- An  implementation  may  provide additional predefined integer types.
   -- It is recommended that  the  names  of such additional types end with
   -- INTEGER as in SHORT_INTEGER  or  LONG_INTEGER.  The  specification of
   -- each operator for the type universal_integer, or for  any  additional
   -- predefined  integer   type,  is  obtained  by  replacing  INTEGER  by
   -- the   name  of the type  in  the specification  of  the corresponding
   -- operator  of the type INTEGER, except  for the  right  operand of the
   -- exponentiating operator.
   -- The universal type universal_real is predefined.
   type FLOAT is implementation_defined;
   -- The predefined operators for this type are as follows:
   -- function "="   (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function "/="  (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function "<"   (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function "<="  (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function ">"   (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function ">="  (LEFT, RIGHT : FLOAT) return BOOLEAN;
   -- function "+"   (RIGHT : FLOAT) return FLOAT;
   -- function "-"   (RIGHT : FLOAT) return FLOAT;
   -- function "\uabs\n" (RIGHT : FLOAT) return FLOAT;
   -- function "+"   (LEFT, RIGHT : FLOAT) return FLOAT;
   -- function "-"   (LEFT, RIGHT : FLOAT) return FLOAT;
   -- function "*"   (LEFT, RIGHT : FLOAT) return FLOAT;
   -- function "/"   (LEFT, RIGHT : FLOAT) return FLOAT;
   -- function "**"  (LEFT : FLOAT; RIGHT : INTEGER) return FLOAT;
   -- An implementation may provide  additional  predefined  floating point
   -- point  types.   It is recommended that the names of  such  additional
   -- types   end   with   FLOAT  as  in  SHORT_FLOAT  or  LONG_FLOAT.  The
   -- specification of each operator for the type  universal_real,  or  for
   -- any  additional  predefined  floating  point  type,  is  obtained  by
   -- replacing  FLOAT by the name of  the type in the specification of the
   -- corresponding  operator  of  the  type  FLOAT.
   -- In  addition,  the  following operators are predefined for  universal
      types:
   -- function "*" (LEFT : universal_integer; RIGHT : universal_real)
      return universal_real;
   -- function "*" (LEFT : universal_real;    RIGHT : universal_integer)
      return universal_real;
   -- function "/" (LEFT : universal_real;    RIGHT : universal_integer)
      return universal_real;
   -- The  type universal_fixed is predefined.  The only operators declared
      for this type are
   -- function "*" (LEFT : any_fixed_point_type; RIGHT :
      any_fixed_point_type)
      return universal_fixed;
   -- function "/" (LEFT : any_fixed_point_type; RIGHT :
      any_fixed_point_type)
      return universal_fixed;
  --  The  following  characters  form  the  standard  ASCII character set.
      set.   Character  literals -- corresponding to control characters are
      not  identifiers;   they  are  indicated  in  italics  in this
      definition.
   type CHARACTER is
          (nul,  soh,  stx,  etx,     eot,  enq,  ack,  bel,
           bs,   ht,   lf,   vt,      ff,   cr,   so,   si,
           dle,  dc1,  dc2,  dc3,     dc4,  nak,  syn,  etb,
           can,  em,   sub,  esc,     fs,   gs,   rs,   us,
           ' ',  '!',  '"',  '#',     '$',  '%',  '&',  ''',
           '(',  ')',  '*',  '+',     ',',  '-',  '.',  '/',
           '0',  '1',  '2',  '3',     '4',  '5',  '6',  '7',
           '8',  '9',  ':',  ';',     '<',  '=',  '>',  '?',
           '@',  'A',  'B',  'C',     'D',  'E',  'F',  'G',
           'H',  'I',  'J',  'K',     'L',  'M',  'N',  'O',
           'P',  'Q',  'R',  'S',     'T',  'U',  'V',  'W',
           'X',  'Y',  'Z',  '[',     '\',  ']',  '~',  '_',
           '`',  'a',  'b',  'c',     'd',  'e',  'f',  'g',
           'h',  'i',  'j',  'k',     'l',  'm',  'n',  'o',
           'p',  'q',  'r',  's',     't',  'u',  'v',  'w',
           'x',  'y',  'z',  '{',     '|',  '}',  '~',  del);
  for CHARACTER use  --  128 ASCII character set without holes
       (0, 1, 2, 3, 4, 5, ..., 125, 126, 127);
  -- The predefined operators for the type CHARACTER are the  same  as  for
     any enumeration type.
  package ASCII is
      --  Control characters:
  NUL   : constant CHARACTER := nul;     SOH   : constant CHARACTER := soh:
  STX   : constant CHARACTER := stx;     ETX   : constant CHARACTER := etx;
  EOT   : constant CHARACTER := eot;     ENQ   : constant CHARACTER := enq:
  ACK   : constant CHARACTER := ack;     BEL   : constant CHARACTER := bel;
  BS    : constant CHARACTER := bs;      HT    : constant CHARACTER := ht;
  LF    : constant CHARACTER := lf;      VT    : constant CHARACTER := vt;
  FF    : constant CHARACTER := ff;      CR    : constant CHARACTER := cr;
  SO    : constant CHARACTER := so;      SI    : constant CHARACTER := si;
  DLE   : constant CHARACTER := dle;     DC1   : constant CHARACTER := dc1;
  DC2   : constant CHARACTER := dc2;     DC3   : constant CHARACTER := dc3;
  DC4   : constant CHARACTER := dc4;     NAK   : constant CHARACTER := nak;
  SYN   : constant CHARACTER := syn;     ETB   : constant CHARACTER := etb;
  CAN   : constant CHARACTER := can;     EM    : constant CHARACTER := em:
  SUB   : constant CHARACTER := sub;     ESC   : constant CHARACTER := esc;
  FS    : constant CHARACTER := fs;      GS    : constant CHARACTER := gs;
  RS    : constant CHARACTER := rs;      US    : constant CHARACTER := us;
  DEL   : constant CHARACTER := del;
      -- Other characters:
EXCLAM    : constant CHARACTER := '!';
QUOTATION : constant CHARACTER := '"';
SHARP     : constant CHARACTER := '#';
DOLLAR    : constant CHARACTER := '$';
PERCENT   : constant CHARACTER := '%';
AMPERSAND : constant CHARACTER := '&';
COLON     : constant CHARACTER := ':';
SEMICOLON : constant CHARACTER := ';';
QUERY     : constant CHARACTER := '?';
AT_SIGN   : constant CHARACTER := '@';
L_BRACKET : constant CHARACTER := '[';
BACK_SLASH: constant CHARACTER := '\';
R_BRACKET : constant CHARACTER := ']';
CIRCUMFLEX: constant CHARACTER := '~';
UNDERLINE : constant CHARACTER := '_';
GRAVE     : constant CHARACTER := '`';
L_BRACE   : constant CHARACTER := '{';
BAR       : constant CHARACTER := '|';
R_BRACE   : constant CHARACTER := '}';
TILDE     : constant CHARACTER := '~';
      -- Lower case letters:
      LC_A : constant CHARACTER := 'a';
      ...
      LC_Z : constant CHARACTER := 'z';
   end ASCII;
       -- Predefined subtypes:
       subtype NATURAL  is INTEGER range 0 .. INTEGER'LAST;
       subtype POSITIVE is INTEGER range 1 .. INTEGER'LAST;
       -- Predefined string type:
       type STRING is \uarray\n(POSITIVE range <>) of CHARACTER;
       pragma PACK(STRING);
       -- The predefined operators for this type are as follows:
       -- function "="  (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function "/=" (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function "<"  (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function "<=" (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function ">"  (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function ">=" (LEFT, RIGHT : STRING) return BOOLEAN;
       -- function "&" (LEFT : STRING;    RIGHT : STRING)    return STRING;
       -- function "&" (LEFT : CHARACTER; RIGHT : STRING)    return STRING;
       -- function "&" (LEFT : STRING;    RIGHT : CHARACTER) return STRING;
       -- function "&" (LEFT : CHARACTER; RIGHT : CHARACTER) return STRING;
type DURATION is delta implementation_defined range implementation_defined;
    -- The  predefined  operators for the type DURATION are the same as for
       any fixed point type.
    -- The predefined exceptions:
   CONSTRAINT_ERROR : exception;
   NUMERIC_ERROR    : exception;
   PROGRAM_ERROR    : exception;
   STORAGE_ERROR    : exception;
   TASKING_ERROR    : exception;
end STANDARD;
Certain  aspects  of the predefined entities cannot be completely described
in the language itself.  For example, although the enumeration type BOOLEAN
can be written showing the two enumeration literals  FALSE  and  TRUE,  the
short-circuit control forms cannot be expressed in the language.
Note:
The language definition predefines the following library units:
    -  The package CALENDAR                         (see 9.6)
    -  The package SYSTEM                           (see 13.7)
    -  The package MACHINE_CODE (if provided)       (see 13.8)
    -  The generic procedure UNCHECKED_DEALLOCATION (see 13.10.1)
    -  The generic function UNCHECKED_CONVERSION    (see 13.10.2)
    -  The generic package SEQUENTIAL_IO            (see 14.2.3)
    -  The generic package DIRECT_IO                (see 14.2.5)
    -  The package TEXT_IO                          (see 14.3.10)
    -  The package IO_EXCEPTIONS                    (see 14.5)
    -  The package LOW_LEVEL_IO                     (see 14.6)
:1800
D.      \uGlossary\n
This  appendix is informative and is not part of the standard definition of
the  Ada  programming  language.   Italicized  terms  in  the   abbreviated
descriptions below either have glossary entries themselves or are described
in entries for related terms.
Accept statement.  See entry.
Access  type.  A value of an access type (an access value) is either a null
value, or a value that designates an object created by an  allocator.   The
designated  object  can  be  read  and  updated  via the access value.  The
definition of an access type specifies the type of the  objects  designated
by values of the access type.  See also collection.
Actual parameter.  See parameter.
Aggregate.   The  evaluation  of an aggregate yields a value of a composite
type.  The  value  is  specified  by  giving  the  value  of  each  of  the
components.  Either positional association or named association may be used
to indicate which value is associated with which component.
Allocator.   The evaluation of an allocator creates an object and returns a
new access value which designates the object.
Array type.  A value of an array type consists of components which are  all
of  the  same  subtype  (and  hence,  of the same type).  Each component is
uniquely distinguished by an index (for a one-dimensional array)  or  by  a
sequence  of  indices (for a multidimensional array).  Each index must be a
value of a discrete type and must lie in the correct index range.
Assignment.  Assignment is the operation that replaces the current value of
a variable by a new value.  An assignment statement specifies a variable on
the left, and on the right, an expression whose value  is  to  be  the  new
value of the variable.
Attribute.    The   evaluation   of   an   attribute  yields  a  predefined
characteristic of a named entity;  some attributes are functions.
Block statement.  A block statement is a single statement that may  contain
a  sequence  of  statements.   It  may also include a declarative part, and
exception handlers;  their effects are local to the block statement.
Body.  A body defines the execution of a subprogram, package, or  task.   A
body  stub  is a form of body that indicates that this execution is defined
in a separately compiled subunit.
Collection.   A  collection  is  the  entire  set  of  objects  created  by
evaluation of allocators for an access type.
Compilation  unit.   A compilation unit is the declaration or the body of a
program unit, presented for compilation as  an  independent  text.   It  is
optionally  preceded  by  a  context clause, naming other compilation units
upon which it depends by means of one more with clauses.
Component.  A component is a value that is a part of a larger value, or  an
object that is part of a larger object.
Composite  type.   A  composite  type  is one whose values have components.
There are two kinds of composite type:  array types and record types.
Constant.  See object.
Constraint.  A constraint determines a subset of the values of a  type.   A
value in that subset satisfies the constraint.
Context clause.  See compilation unit.
Declaration.   A  declaration  associates  an  identifier  (or  some  other
notation) with an entity.  This association is in effect within a region of
text  called  the  scope  of  the  declaration.   Within  the  scope  of  a
declaration, there are places where it is possible to use the identifier to
refer  to the associated declared entity.  At such places the identifier is
said to be a simple name of the entity;  the name is  said  to  denote  the
associated entity.
Declarative  Part.   A  declarative part is a sequence of declarations.  It
may  also  contain  related  information  such  as  subprogram  bodies  and
representation clauses.
Denote.  See declaration.
Derived  Type.   A  derived  type is a type whose operations and values are
replicas of those of an existing type.  The existing  type  is  called  the
parent type of the derived type.
Designate.  See access type, task.
Direct visibility.  See visibility.
Discrete  Type.   A  discrete  type  is  a type which has an ordered set of
distinct values.  The discrete types are the enumeration and integer types.
Discrete types are used for indexing and iteration, and for choices in case
statements and record variants.
Discriminant.  A discriminant is a distinguished component of an object  or
value  of  a  record type.  The subtypes of other components, or even their
presence or absence, may depend on the value of the discriminant.
Discriminant constraint.  A discriminant constraint on  a  record  type  or
private type specifies a value for each discriminant of the type.
Elaboration.   The elaboration of a declaration is the process by which the
declaration achieves its effect (such as creating an object);  this process
occurs during program execution.
Entry.  An entry is used for communication between tasks.  Externally,   an
entry  is  called just as a subprogram is called;  its internal behavior is
specified by one or more accept statements specifying  the  actions  to  be
performed when the entry is called.
Enumeration type.  An enumeration type is a discrete  type whose values are
represented  by enumeration literals which are given explicitly in the type
declaration.   These  enumeration  literals  are  either   identifiers   or
character literals.
Evaluation.   The  evaluation  of an expression is the process by which the
value of the expression is computed.  This process  occurs  during  program
execution.
Exception.   An  exception  is  an  error  situation which may arise during
program execution.  To raise an exception  is  to  abandon  normal  program
execution  so  as  to  signal that the error has taken place.  An exception
handler is  a  portion  of  program  text  specifying  a  response  to  the
exception.   Execution  of  such  a  program  text  is  called handling the
exception.
Expanded name.  An expanded  name  denotes  an  entity  which  is  declared
immediately  within  some  construct.   An  expanded name has the form of a
selected component:  the prefix denotes the construct (a program unit;   or
a  block,  loop,  or accept statement);  the selector is the simple name of
the entity.
Expression.  An expression defines the computation of a value.
Fixed point type.  See real type.
Floating point type.  See real type.
Formal parameter.  See parameter.
Function.  See subprogram.
Generic unit.  A generic unit is a template either for a set of subprograms
or for a set of packages.   A  subprogram  or  package  created  using  the
template   is   called   an  instance  of  the  generic  unit.   A  generic
instantiation is the kind of  declaration  that  creates  an  instance.   A
generic   unit  is  written  as  a  subprogram  or  package  but  with  the
specification prefixed by a generic formal part which may  declare  generic
formal  parameters.   A  generic  formal  parameter  is  either  a  type, a
subprogram, or an object.  A generic unit is one of the  kinds  of  program
unit.
Handler.  See exception.
Index.  See array type.
Index  constraint.   An  index  constraint  for an array type specifies the
lower and upper bounds for each index range of the array type.
Indexed component.  An indexed component denotes a component in  an  array.
It is a form of name containing expressions which specify the values of the
indices  of  the  array component.  An indexed component may also denote an
entry in a family of entries.
Instance.  See generic unit.
Integer type.  An integer type is a discrete type  whose  values  represent
all integer numbers within a specific range.
Lexical  element.   A  lexical  element  is  an  identifier,  a  literal, a
delimiter, or a comment.
Limited type.  A limited type is a type for which  neither  assignment  nor
the  predefined  comparison  for equality is implicitly declared.  All task
types are limited.  A private type  can  be  defined  to  be  limited.   An
equality operator can be explicitly declared for a limited type.
Literal.     A  literal  represents a value literally, that is, by means of
letters and other characters.  A literal is either a  numeric  literal,  an
enumeration literal, a character literal, or a string literal.
Mode.  See parameter.
Model  number.   A model number is an exactly representable value of a real
type.  Operations of a real type are defined in terms of operations on  the
model  numbers  of  the  type.   The properties of the model numbers and of
their  operations   are   the   minimal   properties   preserved   by   all
implementations of the real type.
Name.   A  name  is a construct that stands for an entity:  it is said that
the name denotes the entity, and that the entity  is  the  meaning  of  the
name.  See also declaration, prefix.
Named  association.   A  named  association specifies the association of an
item with one or more positions in a list, by naming the positions.
Object.  An object contains a value.  A program creates an object either by
elaborating an object declaration  or  by  evaluating  an  allocator.   The
declaration  or  allocator specifies a type for the object:  the object can
only contain values of that type.
Operation.  An operation is an elementary action  associated  with  one  or
more  types.   It  is  either implicitly declared by the declaration of the
type, or it is a subprogram that has a parameter or result of the type.
Operator.  An operator is an operation which has one or  two  operands.   A
unary  operator is written before an operand;  a binary operator is written
between two operands.  This notation is a special kind  of  function  call.
An  operator  can be declared as a function.  Many operators are implicitly
declared by the declaration of a type (for example, most type  declarations
imply the declaration of the equality operator for values of the type).
Overloading.   An  identifier  can  have  several alternative meanings at a
given point in the program text:  this property is called overloading.  For
example, an overloaded  enumeration  literal  can  be  an  identifier  that
appears in the definitions of two or more enumeration types.  The effective
meaning   of  an  overloaded  identifier  is  determined  by  the  context.
Subprograms, aggregates,  allocators,  and  string  literals  can  also  be
overloaded.
Package.   A  package specifies a group of logically related entities, such
as types, objects of those types, and subprograms with parameters of  those
types.   It  is  written  as a package declaration and a package body.  The
package declaration has a visible part, containing the declarations of  all
entities that can be explicitly used outside the package.  It may also have
a   private   part   containing   structural   details  that  complete  the
specification of the visible entities, but which are irrelevant to the user
of the package.  The package body contains implementations  of  subprograms
(and  possibly  tasks  as  other  packages) that have been specified in the
package declaration.  A package is one of the kinds of program unit.
Parameter.  A parameter is one of the  named  entities  associated  with  a
subprogram,  entry,  or  generic  unit,  and  used  to communicate with the
corresponding subprogram body, accept statement or generic body.  A  formal
parameter is an identifier used to denote the named entity within the body.
An   actual   parameter  is  the  particular  entity  associated  with  the
corresponding formal parameter by a subprogram call, entry call, or generic
instantiation.  The mode  of  a  formal  parameter  specifies  whether  the
associated  actual  parameter supplies a value for the formal parameter, or
the formal supplies a  value  for  the  actual  parameter,  or  both.   The
association of actual parameters with formal parameters can be specified by
named  associations,  by  positional  associations,  or by a combination of
these.
Parent type.  See derived type.
Positional association.  A positional association specifies the association
of an item with a position in a list, by using the  same  position  in  the
text to specify the item.
Pragma.  A pragma conveys information to the compiler.
Prefix.   A  prefix  is used as the first part of certain kinds of name.  A
prefix is either a function call or a name.
Private part.  See package.
Private type.  A private type is a type whose structure and set  of  values
are clearly defined, but not directly available to the user of the type.  A
private  type is known only by its discriminants (if any) and by the set of
operations defined for it.  A private type and  its  applicable  operations
are  defined in the visible part of a package, or in a generic formal part.
Assignment, equality, and inequality are also defined  for  private  types,
unless the private type is limited.
Procedure.  See subprogram.
Program.   A  program  is composed of a number of compilation units, one of
which is a subprogram called the main program.  Execution  of  the  program
consists  of  execution  of  the main program, which may invoke subprograms
declared in the other compilation units of the program.
Program unit.  A program unit is  any  one  of  a  generic  unit,  package,
subprogram, or task unit.
Qualified  expression.  A qualified expression is an expression preceded by
an indication of its type or subtype.  Such qualification is used when,  in
its   absence,  the  expression  might  be  ambiguous  (for  example  as  a
consequence of overloading).
Raising an exception.  See exception.
Range.  A range is a contiguous set of values of a scalar type.  A range is
specified by giving the lower and upper bounds for the values.  A value  in
the range is said to belong to the range.
Range  constraint.   A  range  constraint  of a type specifies a range, and
thereby determines the subset of the values of the type that belong to  the
range.
Real  type.  A real type is a type whose values represent approximations to
the real numbers.  There are two kinds of real type:  fixed point types are
specified by absolute error bound;  floating point types are specified by a
relative error bound expressed as a number of significant  decimal  digits.
Record  type.   A  value  of a record type consists of components which are
usually of different types or subtypes.  For each  component  of  a  record
value  or  record  object,  the  definition of the record type specifies an
identifier that uniquely determines the component within the record.
Renaming declaration.  A renaming declaration declares another name for  an
entity.
Rendezvous.   A  rendezvous  is  the  interaction  that  occurs between two
parallel tasks when one task has called an entry of the other task,  and  a
corresponding  accept  statement  is  being  executed  by the other task on
behalf of the calling task.
Representation clause.  A representation clause directs the compiler in the
selection of the mapping of a type, an object, or a task onto  features  of
the   underlying   machine   that  executes  a  program.   In  some  cases,
representation clauses completely specify the  mapping;   in  other  cases,
they provide criteria for choosing a mapping.
Satisfy.  See constraint, subtype.
Scalar type.  An object or value of a scalar type does not have components.
A  scalar  type  is either a discrete type or a real type.  The values of a
scalar type are ordered.
Scope.  See declaration.
Selected component.  A selected component is a name consisting of a  prefix
and  of an identifier called the selector.  Selected components are used to
denote record components, entries, and objects designated by access values;
they are also used as expanded names.
Selector.  See selected component.
Simple name.  See declaration, name.
Statement.  A statement specifies one  or  more  actions  to  be  performed
during the execution of a program.
Subcomponent.   A  subcomponent  is  either  a component, or a component of
another subcomponent.
Subprogram.  A subprogram is either a procedure or a function.  A procedure
specifies a sequence  of  actions  and  is  invoked  by  a  procedure  call
statement.   A  function specifies a sequence of actions and also returns a
value called the result, and so  a  function  call  is  an  expression.   A
subprogram  is  written  as  a  subprogram declaration, which specifies its
name, formal parameters, and (for a function) its result;  and a subprogram
body  which  specifies  the  sequence  of  actions.   The  subprogram  call
specifies  the  actual parameters that are to be associated with the formal
parameters.  A subprogram is one of the kinds of program unit.
Subtype.  A subtype of a type characterizes a subset of the values  of  the
type.  The subset is determined by a constraint on the type.  Each value in
the  set  of  values  of a subtype belongs to the subtype and satisfies the
constraint determining the subtype.
Subunit.  See body.
Task.  A task operates in parallel with other parts of the program.  It  is
written  as  a task specification (which specifies the name of the task and
the names and formal parameters of its entries),  and  a  task  body  which
defines its execution.  A task unit is one of the kinds of program unit.  A
task  type  is a type that permits the subsequent declaration of any number
of similar tasks of the type.  A value of a task type is said to  designate
a task.
Type.   A  type characterizes both a set of values, and a set of operations
applicable to those values.  A type definition is a language construct that
defines a type.  A particular type is either an access type, an array type,
a private type, a record type, a scalar type, or a task type.
Use clause.  A use clause achieves direct visibility of  declarations  that
appear in the visible parts of named packages.
Variable.  See object.
Variant  part.   A  variant  part  of a record specifies alternative record
components, depending on a discriminant of the record.  Each value  of  the
discriminant establishes a particular alternative of the variant part.
Visibility.   At  a  given  point  in a program text, the declaration of an
entity with a certain identifier is said to be visible if the entity is  an
acceptable  meaning for an occurrence at that point of the identifier.  The
declaration is visible by selection at the  place  of  the  selector  in  a
selected  component  or  at  the  place of the name in a named association.
Otherwise, the declaration is directly visible, that is, if the  identifier
alone has that meaning.
Visible part.  See package.
With clause.  See compilation unit.
:1900
E.      \uSyntax Summary\n
    2.1
    graphic_character ::= basic_graphic_character
       | lower_case_letter | other_special_character
    basic_graphic_character ::=
         upper_case_letter | digit
       | special_character | space_character
    basic_character ::=
         basic_graphic_character | format_effector
    2.3
    identifier ::=
       letter {[underline] letter_or_digit}
    letter_or_digit ::= letter | digit
    letter ::= upper_case_letter | lower_case_letter
    2.4
    numeric_literal ::= decimal_literal | based_literal
    2.4.1
    decimal_literal ::= integer [.integer] [exponent]
    integer ::= digit {[underline] digit}
    exponent ::= E [+] integer | E - integer
    2.4.2
    based_literal ::=
       base # based_integer [.based_integer] # [exponent]
    base ::= integer
    based_integer ::=
       extended_digit {[underline] extended_digit}
    extended_digit ::= digit | letter
    2.5
    character_literal ::= 'graphic_character'
    2.6
    string_literal ::= "{graphic_character}"
    2.8
    pragma ::=
       pragma identifier [(argument_association
                               {, argument_association})];
    argument_association ::=
         [argument_identifier =>] name
       | [argument_identifier =>] expression
    3.1
    basic_declaration ::=
         object_declaration     | number_declaration
       | type_declaration       | subtype_declaration
       | subprogram_declaration | package_declaration
       | task_declaration       | generic_declaration
       | exception_declaration  | generic_instantiation
       | renaming_declaration   | deferred_constant_declaration
    3.2
    object_declaration ::=
         identifier_list : [constant] subtype_indication [:= expression];
       | identifier_list : [constant] constrained_array_definition
                                                         [:= expression];
    number_declaration ::=
         identifier_list : constant := universal_static_expression;
    identifier_list ::=  identifier {, identifier}
    3.3.1
    type_declaration ::=  full_type_declaration
       | incomplete_type_declaration | private_type_declaration
    full_type_declaration ::=
     type identifier [discriminant_part] is type_definition;
    type_definition ::=
         enumeration_type_definition | integer_type_definition
       | real_type_definition        | array_type_definition
       | record_type_definition      | access_type_definition
       | derived_type_definition
    3.3.2
    subtype_declaration ::=
       subtype identifier is subtype_indication;
    subtype_indication ::=  type_mark [constraint]
    type_mark ::= type_name | subtype_name
    constraint ::=
         range_constraint       | floating_point_constraint
       | fixed_point_constraint | index_constraint
       | discriminant_constraint
    3.4
    derived_type_definition ::= new subtype_indication
    3.5
    range_constraint ::=  range range
    range ::=  range_attribute
       | simple_expression .. simple_expression
    3.5.1
    enumeration_type_definition ::=
       (enumeration_literal_specification
          {, enumeration_literal_specification})
    enumeration_literal_specification ::=  enumeration_literal
    enumeration_literal ::=  identifier | character_literal
    3.5.4
    integer_type_definition ::=  range_constraint
    3.5.6
    real_type_definition ::=
       floating_point_constraint | fixed_point_constraint
    3.5.7
    floating_point_constraint ::=
       floating_accuracy_definition [range_constraint]
    floating_accuracy_definition ::=
       digits static_simple_expression
    3.5.9
    fixed_point_constraint ::=
       fixed_accuracy_definition [range_constraint]
    fixed_accuracy_definition ::=
       delta static_simple_expression
    3.6
    array_type_definition ::=
       unconstrained_array_definition | constrained_array_definition
    unconstrained_array_definition ::=
       \uarray\n(index_subtype_definition {, index_subtype_definition}) of
                component_subtype_indication
    constrained_array_definition ::=
       \uarray\n index_constraint of component_subtype_indication
    index_subtype_definition ::= type_mark range <>
    index_constraint ::=  (discrete_range {, discrete_range})
    discrete_range ::= discrete_subtype_indication | range
    3.7
    record_type_definition ::=
       record
          component_list
       end record
    component_list ::=
          component_declaration {component_declaration}
       | {component_declaration} variant_part
       |  \unull\n;
    component_declaration ::=
       identifier_list : component_subtype_definition [:= expression];
    component_subtype_definition ::=  subtype_indication
    3.7.1
    discriminant_part ::=
       (discriminant_specification {; discriminant_specification})
    discriminant_specification ::=
       identifier_list : type_mark [:= expression]
    3.7.2
    discriminant_constraint ::=
       (discriminant_association {, discriminant_association})
    discriminant_association ::=
       [discriminant_simple_name {| discriminant_simple_name} =>]
                expression
    3.7.3
    variant_part ::=
       case discriminant_simple_name is
           variant
          {variant}
       end case;
    variant ::=
       when choice {| choice} =>
          component_list
    choice ::= simple_expression
       | discrete_range | others | component_simple_name
    3.8
    access_type_definition ::= \uaccess\n subtype_indication
    3.8.1
    incomplete_type_declaration ::=
       type identifier [discriminant_part];
    3.9
    declarative_part ::=
       {basic_declarative_item} {later_declarative_item}
    basic_declarative_item ::= basic_declaration
       | representation_clause | use_clause
    later_declarative_item ::= body
       | subprogram_declaration | package_declaration
       | task_declaration       | generic_declaration
       | use_clause             | generic_instantiation
    body ::= proper_body | body_stub
    proper_body ::=
       subprogram_body | package_body | task_body
    4.1
    name ::= simple_name
       | character_literal  | operator_symbol
       | indexed_component  | slice
       | selected_component | attribute
    simple_name ::= identifier
    prefix ::= name | function_call
    4.1.1
    indexed_component ::= prefix(expression {, expression})
    4.1.2
    slice ::= prefix(discrete_range)
    4.1.3
    selected_component ::= prefix.selector
    selector ::= simple_name
       | character_literal | operator_symbol | \uall\n
    4.1.4
    attribute ::= prefix'attribute_designator
    attribute_designator ::=
       simple_name [(universal_static_expression)]
    4.3
    aggregate ::=
       (component_association {, component_association})
    component_association ::=
       [choice {| choice} => ] expression
    4.4
    expression ::=
         relation {and relation} | relation {\uand\n then relation}
       | relation {or relation}  | relation {or else relation}
       | relation {xor relation}
    relation ::=
         simple_expression [relational_operator simple_expression]
       | simple_expression [not] in range
       | simple_expression [not] in type_mark
    simple_expression ::=
       [unary_adding_operator] term {binary_adding_operator term}
    term ::= factor {multiplying_operator factor}
    factor ::= primary [** primary] | \uabs\n primary | not primary
    primary ::=
         numeric_literal | \unull\n | aggregate | string_literal
       | name | allocator | function_call | type_conversion
       | qualified_expression | (expression)
    4.5
    logical_operator  ::=  \uand\n | or | xor
    relational_operator  ::=  = | /= | < | <= | > | >=
    binary_adding_operator  ::=  + | - | &
    unary_adding_operator  ::=  + | -
    multiplying_operator  ::=  * | / | mod | rem
    highest_precedence_operator  ::=  ** | \uabs\n | not
    4.6
    type_conversion ::= type_mark(expression)
    4.7
    qualified_expression ::=
       type_mark'(expression) | type_mark'aggregate
    4.8
    allocator ::=
       new subtype_indication | new qualified_expression
    5.1
    sequence_of_statements ::= statement {statement}
    statement ::=
       {label} simple_statement | {label} compound_statement
    simple_statement ::= null_statement
       | assignment_statement | procedure_call_statement
       | exit_statement       | return_statement
       | goto_statement       | entry_call_statement
       | delay_statement      | abort_statement
       | raise_statement      | code_statement
    compound_statement ::=
         if_statement     | case_statement
       | loop_statement   | block_statement
       | accept_statement | select_statement
    label ::= <<label_simple_name>>
    null_statement ::= \unull\n;
    5.2
    assignment_statement ::=
       variable_name := expression;
    5.3
    if_statement ::=
        if condition then
          sequence_of_statements
       {elsif condition then
          sequence_of_statements}
       [else
          sequence_of_statements]
        end if;
    condition ::= boolean_expression
    5.4
    case_statement ::=
       case expression is
           case_statement_alternative
          {case_statement_alternative}
       end case;
    case_statement_alternative ::=
       when choice {| choice } =>
          sequence_of_statements
    5.5
    loop_statement ::=
       [loop_simple_name:]
          [iteration_scheme] loop
             sequence_of_statements
           end loop [loop_simple_name];
    iteration_scheme ::= while condition
       | for loop_parameter_specification
    loop_parameter_specification ::=
       identifier in [reverse] discrete_range
    5.6
    block_statement ::=
       [block_simple_name:]
          [declare
               declarative_part]
           begin
               sequence_of_statements
          [exception
               exception_handler
              {exception_handler}]
           end [block_simple_name];
    5.7
    exit_statement ::=
       exit [loop_name] [when condition];
    5.8
    return_statement ::= return [expression];
    5.9
    goto_statement ::= goto label_name;
    6.1
    subprogram_declaration ::= subprogram_specification;
    subprogram_specification ::=
         procedure identifier [formal_part]
       | function designator  [formal_part] return type_mark
    designator ::= identifier | operator_symbol
    operator_symbol ::= string_literal
    formal_part ::=
       (parameter_specification {; parameter_specification})
    parameter_specification ::=
       identifier_list : mode type_mark [:= expression]
    mode ::= [in] | in out | out
    6.3
    subprogram_body ::=
        subprogram_specification is
           [declarative_part]
        begin
            sequence_of_statements
       [exception
            exception_handler
           {exception_handler}]
        end [designator];
    6.4
    procedure_call_statement ::=
       procedure_name [actual_parameter_part];
    function_call ::=
       function_name [actual_parameter_part]
    actual_parameter_part ::=
       (parameter_association {, parameter_association})
    parameter_association ::=
       [formal_parameter =>] actual_parameter
    formal_parameter ::= parameter_simple_name
    actual_parameter ::=
       expression | variable_name | type_mark(variable_name)
    7.1
    package_declaration ::= package_specification;
    package_specification ::=
        package identifier is
          {basic_declarative_item}
       [private
          {basic_declarative_item}]
        end [package_simple_name]
    package_body ::=
        package body package_simple_name is
           [declarative_part]
       [begin
            sequence_of_statements
       [exception
            exception_handler
           {exception_handler}]]
        end [package_simple_name];
    7.4
    private_type_declaration ::=
       type identifier [discriminant_part] is [limited] private;
    deferred_constant_declaration ::=
       identifier_list : constant type_mark;
    8.4
    use_clause ::= use package_name {, package_name};
    8.5
    renaming_declaration ::=
         identifier : type_mark   renames object_name;
       | identifier : exception   renames exception_name;
       | package identifier       renames package_name;
       | subprogram_specification renames subprogram_or_entry_name;
    9.1
    task_declaration ::= task_specification;
    task_specification ::=
       task [type] identifier [is
          {entry_declaration}
          {representation_clause}
       end [task_simple_name]]
    task_body ::=
        task body task_simple_name is
           [declarative_part]
        begin
            sequence_of_statements
       [exception
            exception_handler
           {exception_handler}]
        end [task_simple_name];
    9.5
    entry_declaration ::=
       entry identifier [(discrete_range)] [formal_part];
    entry_call_statement ::=
       entry_name [actual_parameter_part];
    accept_statement ::=
       \uaccept\n entry_simple_name [(entry_index)] [formal_part] [do
          sequence_of_statements
       end [entry_simple_name]];
    entry_index ::= expression
    9.6
    delay_statement ::= delay simple_expression;
    9.7
    select_statement ::= selective_wait
       | conditional_entry_call | timed_entry_call
    9.7.1
    selective_wait ::=
        select
          select_alternative
       {or
          select_alternative}
       [else
          sequence_of_statements]
        end select;
    select_alternative ::=
       [when condition =>]
          selective_wait_alternative
    selective_wait_alternative ::= accept_alternative
       | delay_alternative | terminate_alternative
    accept_alternative  ::=
       accept_statement [sequence_of_statements]
    delay_alternative  ::=
       delay_statement [sequence_of_statements]
    terminate_alternative ::= terminate;
    conditional_entry_call ::=
       select
           entry_call_statement
          [sequence_of_statements]
       else
           sequence_of_statements
       end select;
    9.7.3
    timed_entry_call ::=
       select
           entry_call_statement
          [sequence_of_statements]
       or
           delay_alternative
       end select;
    9.10
    abort_statement ::= \uabort\n task_name {, task_name};
    10.1
    compilation ::= {compilation_unit}
    compilation_unit ::=
         context_clause library_unit
       | context_clause secondary_unit
    library_unit ::=
         subprogram_declaration | package_declaration
       | generic_declaration    | generic_instantiation
       | subprogram_body
    secondary_unit ::= library_unit_body | subunit
    library_unit_body ::= subprogram_body | package_body
    10.1.1
    context_clause ::= {with_clause {use_clause}}
    with_clause ::=
       with unit_simple_name {, unit_simple_name};
    10.2
    body_stub ::=
         subprogram_specification is separate;
       | package body package_simple_name is separate;
       | task body task_simple_name is separate;
    subunit ::= separate (parent_unit_name) proper_body
    11.1
    exception_declaration ::= identifier_list : exception;
    11.2
    exception_handler ::=
       when exception_choice {| exception_choice} =>
          sequence_of_statements
    exception_choice ::= exception_name | others
    11.3
    raise_statement ::= raise [exception_name];
    12.1
    generic_declaration ::= generic_specification;
    generic_specification ::=
         generic_formal_part subprogram_specification
       | generic_formal_part package_specification
    generic_formal_part ::= generic {generic_parameter_declaration}
    generic_parameter_declaration ::=
         identifier_list : [in [out]] type_mark [:= expression];
       | type identifier is generic_type_definition;
       | private_type_declaration
       | with subprogram_specification [is name];
       | with subprogram_specification [is <>];
    generic_type_definition ::=
         (<>) | range <> | digits <> | delta <>
       | array_type_definition | access_type_definition
    12.3
    generic_instantiation ::=
         package identifier is
             new generic_package_name [generic_actual_part];
       | procedure identifier is
             new generic_procedure_name [generic_actual_part];
       | function designator is
             new generic_function_name [generic_actual_part];
    generic_actual_part ::=
       (generic_association {, generic_association})
    generic_association ::=
       [generic_formal_parameter =>] generic_actual_parameter
    generic_formal_parameter ::=
       parameter_simple_name | operator_symbol
    generic_actual_parameter ::= expression | variable_name
       | subprogram_name | entry_name | type_mark
    13.1
    representation_clause ::=
         type_representation_clause | address_clause
    type_representation_clause ::= length_clause
       | enumeration_representation_clause
       | record_representation_clause
    13.2
    length_clause ::= for attribute use simple_expression;
    13.3
    enumeration_representation_clause ::=
       for type_simple_name use aggregate;
    13.4
    record_representation_clause ::=
       for type_simple_name use
          record [alignment_clause]
             {component_clause}
          end record;
    alignment_clause ::= at mod static_simple_expression;
    component_clause ::=
       component_name at static_simple_expression
                      range static_range;
    13.5
    address_clause ::=
       for simple_name use at simple_expression;
    13.8
    code_statement ::= type_mark'record_aggregate;
:2000
F.      \uImplementation-Dependent Characteristics\n
This appendix is not part of the standard definition of the Ada programming
language.
The  Ada  language  definition  allows for certain machine-dependences in a
controlled manner. No machine-dependent syntax or  semantic  extensions  or
restrictions  are  allowed.   The  only  allowed implementation-dependences
correspond to  implementation-dependent  pragmas  and  attributes,  certain
machine-dependent  conventions  as  mentioned  in  chapter  13, and certain
allowed restrictions on representation clauses.
The reference manual of each Ada implementation must  include  an  appendix
(called   Appendix   F)   that   describes   all   implementation-dependent
characteristics.  The appendix F for a given implementation  must  list  in
particular:
(1)  The form, allowed places, and effect of every implementation-dependent
     pragma.
(2)  The name and the type of every implementation-dependent attribute.
(3)  The specification of the package SYSTEM.
(4)  The list of all restrictions on representation clauses (see 13.1)
(5)  The conventions used for any  implementation-generated  name  denoting
     implementation-dependent components (see 13.4).
(6)  The interpretation of expressions  that  appear  in  address  clauses,
     including those for interrupts (see 13.5).
(7)  Any restriction on unchecked conversions (see 13.10.2).
(8)  Any  implementation-dependent  characteristics  of  the   input-output
     packages (see 14).